Six features of a good user story - INVEST model renewed

November 5, 2008 by Artem

"As a Product Owner and the development team we want to have user stories of the appropriate size so that we could plan realistically while not wasting time on estimating and managing what would anyway will be changed" - A possible user story.

User stories are the the most used format for agile requirements. The main point of the user stories is to focus on the concrete user needs and not on figuring out the extensive amount details that are known to be difficult to gather upfront. A usual recommendation for stories to make more sense is to follow the INVEST acronym popularized by Mike Cohn in his books on user stories and on estimating and planning . According to these books and various online recommendations a good user story should be:

• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

You can find more explanation on what each of the component means in the popular Vaibhav's post. What I would like you to discuss today is the "small" component of the INVEST recommendation. According to it a good story shouldn't be big, ideally no bigger, than 2-3 person-weeks of effort. That is indeed helpful for the team to work on the relatively small requirements. However, that recommendation is in the direct conflict with the product backlog iceberg concept that expects very detailed requirements on the top and rather huge requirements on the bottom that usually corresponds to the level of the requirement understanding. Requiring all the stories to be small

• would be very difficult if possible at all for any large project
• would project the false level of understanding of all the small requirements for the system
• would require huge amount of estimation work much of which would be rendered moot as the requirements to any system inevitably change during implementation

Opinions change over time and lately Mike Cohn teaches the different INVEST model. According to it a good user story should be:

• Independent
• Negotiable
• Valuable
• Estimatable
• Sized appropriately
• Testable

In my opinion, that is a significantly better definition that I try to apply myself. An appropriately sized story on the top of the product backlog should be small enough for the team to realistically plan tasks for it. An appropriately sized story or epic from the further future should be bigger and the furthest stories can be really huge reflecting the level of the the detail understanding.

Your experience

How do you size your own requirements? Are you following any size-related guidelines to aid the planning?

Permalink