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:
But let’s see what acronyms from INVEST means.
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.
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.
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.
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.
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.
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
This article is part of a bigger topic called: