Book a call

Agile INVEST - 6 great user stories guidelines

Adrian Sita
2 Aug, 2019
3 m read

Agile INVEST for user stories

Agile uses user stories to express the problems/issues that a product or system should resolve. Agile INVEST guidelines are a set of recommendations put together by Bill Wake to test good quality user stories (or more general, Product Backlog Items) that can help you in your Agile project management.

According to the Agile INVEST guidelines, a high-quality user story is easy to:

  • understand

  • implement

  • test

  • show to the client - demo

  • independent

But let’s see what acronyms from INVEST means.

agile invest

Agile INVEST - Independent

This means that can exist as a PBI (product backlog item) by its priority, independently valued, and not dependent on any other story.

The user story priority assigned should be the only factor to determine when the team will implement the story. If its priority is lower, the user story goes lower in the backlog and therefore implemented later while if it is higher, the team will move it up in the backlog so the implementation will happen sooner. If user stories depend on each other, then the dependency will determine when the team will implement the user story, rather than the priority.

Agile INVEST - Negotiable

A good user story captures the essence of the customers’ requirements. If there are questions than the team discuss with the client to identify the right value of this story that the development team can negotiate with the product owner and stakeholders. In this way, the collaboration between the team of the project (supplier and client team) can bond each other to create great products/services.

The agile teams have nothing left to ask, everything’s documented on the agile user story? Then the business analysts write the requirements.

There will be some non-negotiable items (usually non-functional), like

- security policies related to user accounts

- 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.

Agile INVEST - Valuable/Vertical

By referring to Agile Principles, valuable means that we can show a feature or something that a client requested in the sprint review meeting.

When splitting user stories, the team must split vertically (stand also for V) instead of horizontally. To offer an entire functionality to have an incremental shippable product at the end of the sprint

Technical PBI is always more interesting for the team to implement, but, they do not always bring direct value to the customer, 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.

Agile INVEST - Estimable

A great user story must be estimable. In Agile, estimation is relative; 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.

This discussion around estimates brings the entire team to a shared understanding of what it requires completing the user story. Sometimes the stories are not estimable and this is normal because the story is too big or has several features in the same story. Here, we should split the story into multiple stories. In other cases, the story has too many unknowns requiring research.

Agile INVEST - Small

Stories should take from a few hours to the maximum sprint length. Otherwise will appear different issues like velocity (how the team is accountable for the delivered points), estimation is hard to be accurate, etc.

Agile INVEST - Testable

Testable in this case is referring in this case to analyze the acceptance criteria defined.

We cannot consider this user story "Done" unless it satisfies the acceptance criteria. And the only way we know, if it's satisfied, is by verifying it through tests.

Acceptance criteria are not test cases. 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.

The customer can tell you which is the test environment and the test conditions for how the team can consider DONE a user story.

Some (final) thoughts

With the right stories, we assure half of the road to success. Follow INVEST to create brilliant user stories that will be easy to understand by business and technical teams.

This article is part of a bigger topic called: 


Resources related articles

Agile HR

Writing User Stories

Related Articles


Subscribe to knowledge
© BrainConcert 2022 All rights reserved