Get Free Widget

Agile INVEST guidelines

INVEST Guidelines - Independent User Stories

INVEST Guidelines are a set of recommendations put together by Bill Wake to evaluate good quality user stories (or more general, Product Backlog Items). Each of the letters from INVEST mnemonic refers to quality characteristics and for the next six parts, each characteristic will be presented in detail. 

The first characteristic is Independent. An independent user story can be estimated, developed, tested, and demonstrated to the client, independently. This allows it to be positioned in the product backlog by its priority, independently valued, and not dependent on any other user stories before it can be implemented. 

According to the INVEST guidelines, a high-quality user story can be understood, implemented, tested, and demonstrated on its own. It can also be independently valued by itself in the product backlog. This allows it to move up and down in the product backlog as its priority changes, without affecting any other user stories. The priority assigned to the user story should be the only factor to determine when is implemented so if its priority is lower, the user story goes lower in the backlog and therefore implemented later while if it is higher, it can be moved up in the backlog so it is implemented sooner. Ideally, the time when the user story will be implemented should be determined only on its priority, independent of other user stories in the backlog. If user stories are dependent on each other, then the dependency will determine when the user story is implemented, rather than the priority. 

In the beginning, those user stories that define the system's foundation are written. These early user stories will deliver a slice of functionality to the user that can be demonstrated.

agile invest

INVEST Guidelines - Negotiable Criteria

In this second part, it is analysed the meaning of N from INVEST mnemonic: Negotiable. According to the guidelines, a good user story should capture the essence of the customers'’ requirements. It's not an explicit contract with all the information needed to do the analysis, design, code, and test of this feature. This puts the team in the context of having questions, they need to discuss with the product owner, and stakeholders, to negotiate what this user story is really trying to express. Now as the user story is developed through these negotiations, details are added until the team understands exactly what the story is describing enough to estimate a level of effort. One of the most important questions the team should ask is how will I know I have done that? This tells them how to write acceptance criteria to determine when the story is done. 

Clear acceptance criteria tell the developer how the feature will be tested and gives QA a solid foundation for writing the test plans. If the product owner cannot describe how to know when the feature is complete, more research is needed. During the product grooming meeting, user stories can be changed, rewritten, split, or even deleted, depending on the state of the project and the business needs. And those business needs change as the project progresses. With the product owner's vision, the team will fill in the details of how these user stories are implemented during the Sprint. And the customer will correct that vision or add to the details when the feature is demonstrated at the sprint review meeting, which could lead to modifying existing user stories in the product backlog or adding new ones. What is crucially important is to capture any and all agreements made during collaboration and negotiations into the related user stories, so everyone is on the same page and agreements are not lost. 

By putting concrete and strict elements from the beginning into the user story doesn't really makes it clearer and easier to develop. Besides the fact that the Product Owner should not focus on details about how the user story should be implemented and only on what needs to be implemented, a very detailed description will present just one perspective on the customer requirement and will block any possibility of discussion and debate to really understand all aspect of it. The team has nothing left to ask, everything's documented. It becomes just the old-school way of writing requirements, with no collaboration opportunities between the team and the end-user or the stakeholders. 

Now there will always be some non-negotiable items, like for example security policies related to user accounts, or performance requirements like the number of simultaneous users that the system has to handle. This is fine, as long as the details of the feature itself are open-ended inviting a conversation. 

The "N" in the INVEST guidelines stands for Negotiable. The capability of writing open-ended user stories that invite negotiations enables collaboration between the team and the stakeholders, which leads to the creation of a product which satisfies the users needs, resulting in happy customers.

INVEST Guidelines - Valuable Criteria

In this third part, it is analysed the meaning of V from INVEST mnemonic: Valuable. A good user story must define something that is of value to the end-user. This could include a feature, performance requirement, or something the user has asked for and can be demonstrated in the sprint review meeting. Technical Product Backlog items are always more interesting for the team to implement, however they do not always bring value to the customer (or at least value that he can perceive when using the system), and this comes in contradiction with one of the Agile principles which are stating satisfy the customer through early and continuous delivery of valuable software (all Agile Principles).

This doesn't mean that you should not have technical Product Backlog Items. One example is a SPIKE. A SPIKE is where the team investigates, researches, and prototype so they understand a fuzzy area well enough to be able to estimate it. But SPIKES need to be time-boxed, they have to have clear goals, and an outcome that's expected. This ensures the SPIKE stays focused using only the time needed to satisfy the goals and the outcome. Letting a SPIKE turn into an opportunity for the team to do fun research and prototyping not related to the issue in the SPIKE, does not deliver value to the end-user. 

Besides standing for valuable, the V letter can also refer to vertical because when splitting user stories, they should be split vertically instead of horizontally. A horizontal user story will include a complete layer of functionality - network, database architecture, persistent data, some logic, or the user interface, depending on the product architecture. So, for example, if the user story says: create the product database, the team will create the database and that's it, we have a database at the end. But database solely, although you cannot have a functional product without it (usually data has to be stored somewhere), is not of value to the customer. The customer does not interact with the database directly, he is using features of the software product. What good is a database without the user interface so it can be viewed and demonstrated? A vertical slice of functionality will have a little of each of those horizontal layers so there will be some database, some logic, some presentation in each user story. Something that can be demonstrated as working code. Coming back to one of the examples used in a previous article, a user needs to be able to register himself in an online application, it is clear that, to implement this user story, the team:

  • will need to design and implement a part of the database where the user information will be stored, 

  • will create the user interface through which the user will provide its information for registration, 

  • will implement validations of the input data and then the persistence of it into the database,

  • will ensure the proper communication between the webserver where the application is running and the database server where the database is stored.

This is a small vertical slice and it's a value to the user. Now it's important to remember, value is not value in the business sense that you can sell this feature. This user story is much too small a slice of functionality, it's not going to be a business money maker all by itself. And normally, several of these user stories are needed to completely flush out a full feature. However, each user story needs to provide a slice of the feature that is of value to the user. The "V" in the INVEST guidelines stands for Valuable and what is considered valuable is always in the eyes of the end-user.

INVEST Guidelines - Estimable Criteria

In this fourth article, it is analysed the meaning of E from INVEST mnemonic: Estimable. A high-quality user story must be estimable. Usually, in Agile, estimation is a relative one; relative to the rest of the user stories in the backlog. Various methods are popular: Fibonacci series of numbers, T-shirt sizes (small, medium, large), etc. The effort consumed by the team to put a relative estimate on a user story should be minimal, but all team members must agree on the estimate before it is recorded. 

But in order to provide a good estimate, the team must understand the user story. The user story must be small and focused; the acceptance criteria need also to be known and clear because the estimation must cover the design, development, testing, and documentation of the feature implemented.

Getting a user story to this point requires negotiation between the team, product owner, and customer. If the user story is not clearly defined or scope, the team will not be able to estimate the level of effort. And the estimate is important because it's used to determine if the user story can be completed in the single sprint. Once the team has a stable velocity, the user story estimates help them determine which user stories will be pulled in the next sprint. Let's say that the team has a velocity of 7, and the two-top-level user-stories in the Product Backlog have 4 and 6 story points. The second user story cannot be pulled in the same sprint with the first one because then the Spring Backlog will have 11 story points while the velocity of the team is only 7. In this case, either the second user story is planned for another sprint, or the team can look into it to see if it cannot be split is smaller user stories which can be handled in the current sprint. 

Also, the rule that every team member needs to agree on the estimate almost guarantees discussions that'll bring out uncovered assumptions and missing requirements. If the QA team member thinks the story is large, while the GUI team member thinks it's small, there's obviously something one knows or assumes the others is not aware of. More discussion is needed to fully understand the user story. This discussion around estimates brings the entire team to a shared understanding of what is required to complete the user story. Now when a user story cannot be estimated, it is because the team cannot get their collective head around the entire story. This is normally because the story is too big or has several different features in the same story. In this case, the story should be split into multiple stories. In other cases, the story has too many unknowns requiring research. 

A user story that is unclear will normally be estimated quite large by the team. Even if a user story is a high priority, if it can't be pulled into a sprint, it can't be worked. Now, these large user stories probably contain multiple features which are each at different priorities. Splitting a user story into its component features allows each feature to be prioritized individually in the product backlog. Lastly, the team is solely responsible for estimating the level of effort. The product owner says what will be delivered by maintaining and prioritising the product backlog, but the team says how much effort each product backlog Item will take to implement. 

The "E" in the INVEST guidelines stands for Estimable. The feature or requirement described in the user story and its acceptance criteria must be clearly understood by the team in order for them to give an accurate estimate of effort.

INVEST Guidelines - Small Criteria

In this fifth part, it is analysed the meaning of S from INVEST mnemonic: Small. High-quality user stories are small or sized appropriately. Stories represented up to few days of work (or few stories points depending on how the estimations are done) and fit in a sprint are considered small. Also, ideally, should be implemented by a single person in the team. If more than one person is required then perhaps it should have been split from the beginning. Opposite to this, we can have two cases:

  • A user-story that actually contains more than one feature to implement. If a lot of information is provided then this is an indication that the user-story has to be split. The estimation will be too big, not fitting a sprint.

  • A user-story very fuzzy described, not clear details, no acceptance criteria. This is a sign that is not clear what the user expects, so no estimations can be done here. Usually, these stories at the end hide more than one features, are rather and will become as described previously.

These types of user stories, that are too big and contains several features, are considered EPICs and they should be split into several user stories that are small enough to understand and estimate. The team will provide more accurate estimates for smaller user stories. 

Splitting user stories is a deferred activity. Stories at the bottom of the backlog are going to be very large and fuzzy, with very little detail. As long as they are not highly important to the customer (with great value), makes no sense to invest effort in clarifying them. Might be the case that at the end some of them will never be implemented. It time, as implementation is progressing, the whole project could change, the customer focus could change, and these could change. So, it's okay for them to be fuzzy and large. 

As items at the top of the product backlog will be implemented, as being high priority items, these will move up and they need to be split into large user stories, they're not small enough to really do an estimate for yet, but they're much easier to understand and discuss to see how to split them up even further. 

For example, there is a requirement from the customer that the system offers some reporting. This is at the beginning. Reporting is a very large topic, so, without further discussions, is very fuzzy. Normally it goes to the end of the product backlog. Once other higher priority features are implemented, the discussion about reporting will begin. Then, the customer indicates what reports he wants to be provided by the application, in what format, if the reports are predefined or an interface should allow the user to dynamically define it, etc. At this point, the initial user-story (which was more like an EPIC) is split into several other user stories. But still quite big some of them (for example the feature to implement a user interface for dynamic report generation is not a small feature).

Once they get to the top of the product backlog, this is where they have to be sized appropriately, split further if need it, because these are about ready to be worked, to be pulled into a sprint to be worked. 

They need to be discussed, details added, acceptance criteria have to be good, and they need to have a good estimate assigned to them. 

INVEST Guidelines - Testable Criteria

In this sixth and final part, it is analysed the meaning of T from INVEST mnemonic: Testable. When discussing this aspect, usually it comes down to analyse the acceptance criteria defined. This user story cannot be considered "Done" unless the acceptance criteria are satisfied. And the only way we know, if it's satisfied, is by verifying it through tests, but acceptance criteria are not tested cases. Acceptance criteria answer the question, how will I know when I'm done with this user story? Test cases list the steps needed to test the functionality. 

When writing acceptance criteria, individuals from three different disciplines are required, to collectively understand what should be tested and how. The product owner, the team members who will be doing the development, and the ones who will be doing the testing. All three must be in agreement on what needs to be done in order to satisfy the user story. Tests can be manual or automated (unit tests, integration tests), doesn't matter at this point.

Acceptance criteria should be detailed enough to define when the user story is satisfied, yet not so detailed as to inhibit collaboration. And all agreements should also be captured in the user story. So, there are no misunderstandings if someone new is added to the team and ends up doing the work. The acceptance criteria are used to create the test plan, and it's a best practice to write the test plan before developing the code. It makes it very clear to the team what they need to do to move this user story to "Done". If the team knows exactly how the feature will be tested, they will know exactly how to implement it, which increases the team's productivity. A way to ensure the user's story is testable is have the customer that submitted this user story tell the team how to test it. If the customer cannot describe how to test a feature, it means there's more discussion needed. If the test criteria are difficult to write, then there's a problem with the user story. 

When writing the test criteria to be aware of descriptions that are not testable. Words must be exact. Words like "all" mean you never know when you're done testing.

Now when the user story is new and very large like an epic, fuzzy words can promote a conversation and negotiations. In this case, they would help the team and stakeholders, come to a single idea of what it means to be user-friendly or clean. But they don't belong in that acceptance criteria, which you're going to be using to write your test plans. Now all these agreements that the team comes to, must be written in the user stories acceptance criteria in clear, concise, testable language. Also, what's essential to capture notes, assumptions, and agreements in the user story. Too much information in a description can lead to missing information and acceptance criteria. Here we see, customers should be restricted to more than five comments in a single day. Well, that's something that should be in the test plan, but down here, logged in user should be able to submit comments on plant files relaying to their own experience. This doesn't bring that in and so it could be left out of the test plan. Ensure that the assumptions captured in the description are also reflected in the acceptance criteria. 

The "T" in the INVEST guidelines stands for Testable. Writing clear, testable acceptance criteria is crucial as it's the only way the team, product owner, and customer, can agree on when the user story is done.

Some (final) thoughts shape-1

Having the right stories half of the road to success is assured

Follow INVEST to have great user stories that will be easy to understand by technical and business teams

 

This article is part of a bigger topic called Agile Project Management

Agile Project Management

  • Twitter
  • FaceBook
  • LinkedIn
  • YouTube