Dirkjan: Created page with "INVEST is an acronym that descibes the properties of a good user story: * '''I'''ndependent * '''N'''egotiable * '''V'''alue * '''Es'''timable * '''T'''estable # First, they..."

2020-08-25T09:51:30Z

Created page with "INVEST is an acronym that descibes the properties of a good user story: * '''I'''ndependent * '''N'''egotiable * '''V'''alue * '''Es'''timable * '''T'''estable # First, they..."

New page

INVEST is an acronym that descibes the properties of a good user story:

* '''I'''ndependent
* '''N'''egotiable
* '''V'''alue
* '''Es'''timable
* '''T'''estable

# First, they should be as '''Independent''' as possible.
##After all, the more independent they are from each other, the easier it is to change the priorities between stories. No doubt this might be difficult to achieve sometimes, but quite often you can fix that by splitting a big story or combining two small stories.
# The second requirement is that a story should be '''Negotiable''',
## which means that the description of a story should promote a discussion later on in the project. As I wrote earlier, stories are no substitute for the functional design, but rather a reminder to discuss the details with the product owner just-in-time. If you write stories that provide too much detail upfront, then you might give the impression that no discussion is needed anymore and that would go against the entire essence of user stories.
# The third requirement, '''Value''',
##demands that a user story must have business value. Take for instance the product catalog application I’ve mentioned before. A screen for adding products has no business value on its own. After all, as long as a potential customer cannot see those products yet, such a screen would not make a difference. Building both screens fully with all its bells-and-whistles is not an option either. But the product owner might just accept a first version that limits the customer functionality to a list of products with a description and a price. The ability to attach a product image could be built in the next version and is a separate user story. Unfortunately, breaking down functionality like that is not trivial, so it is important to work with the product owner to see which story has sufficient business value.
# The fourth requirement states that every story must be '''Estimable'''
## This may sound silly, but once you find it difficult to estimate the size of a user story, it is very likely that the scope of that story is too wide. However, it’s normal that the estimates for stories that will be picked up at a later stage of the project are very rough. In fact, any attempt to provide a more detailed estimate may create the illusion that the key decisions were already made at the time of creation. As mentioned earlier in this article, it is important to estimate at the last responsible moment when you have the most up to date information available.
## An obvious solution for ensuring that user stories are estimable is by keeping them small. A good sanity check that I've read somewhere in a blog is to ask someone in the team for an estimate for a fairly big story. If he or she answers that question with something along the line like: "Uhm, something like a month or so" then you can bet that the developer has no idea about the content and scope of the story. In that case it is not unwise to try to split this story into several smaller stories that still have business value but which scope is very limited.
# And that brings us to the last letter of the acronym - the 't' for '''testable'''
## Not to be confused with automated testing or something like that. Instead, it refers to the fact that a user story must include acceptance criteria that should allow verification that the team’s interpretation of the story matches the original intention of the product owner. As the product owner has not seen the end-result yet, getting those criteria might get challenging sometimes. What could be helpful is to ask him how he would demonstrate that feature other users. In typical Scrum methodology for that is the how-to demo part of a story.
[[Category:roadmapping]]

[[Category:Writing Use Cases]]

INVEST - Revision history

Dirkjan: Created page with "INVEST is an acronym that descibes the properties of a good user story: * '''I'''ndependent * '''N'''egotiable * '''V'''alue * '''Es'''timable * '''T'''estable # First, they..."