INVEST in Good User Stories

In Scrum development, User Stories are the vehicle by which stakeholders identify and prioritize application features and requirements. On the first day of each new Scrum sprint, the Team and Product Owner meet to negotiate the sprint. User Stories are the terms of that negotiation and Story Points are the currency of the negotiated contract.

Bad User Stories are vague, broad, subjective, and hard to test or prove. They create confusion for the Team and frustration for the other stakeholders. Bad Stories want everything without anything in particular or they want nothing as if it were something. They get put near the bottom of the Product Backlog and are a drag on the project’s closure because if a Story gets to the Sprint Planning Meeting and then is determined to be too big or otherwise cumbersome (e.g., is it too hard to test), it might get discarded and delayed. Having a story delayed may not be best for the business, so it pays to take time to write solid User Stories.

Good User Stories are independent thoughts with genuine business value; they move the project forward with clarity. A good User Story reads like “As a stakeholder, I want a single sign-on so that I can have access to all my applications with only one user name and password;” or “As a designer, I want a custom color picker that will insert the correct hexadecimal color into my active file editor so that I don’t have to make the conversion manually each time.”

The relative size of User Stories is important. Good User Stories are estimable and always sized small enough to fit into a sprint. During Backlog Grooming or Planning Poker, with only a few minutes to discuss details with the Product Owner, the Team has to be able to assign a relatively accurate Story Point value to a given Story. Days or weeks later, when the Team accepts that Story into a sprint, they must also be able to decompose that Story into specific, estimable units of work and then complete those tasks during the sprint.

In addition to appropriate sizing, a good User Story is able to be proven; it must be testable. The Story about the single sign-on is an example of a Story that could be easily demonstrated at the end-of-sprint demonstration. A User Story that is too vague to be testable is likely to be found lower on the Product Backlog list because the Team is going to have a hard time committing to a Story that can’t be clearly demonstrated as complete. “As a user, I want a delightful user experience so that my life can continue to be puppy dogs and rainbows” is the kind of ambiguous and meaningless Story that is never going to make it out of a Sprint Planning meeting.

Good User Stories have wiggle room in what constitutes “done.” The conditions of satisfaction for the Story must be clear and the Story itself must be testable so that the conditions can be proven, but remember that the sprint is the negotiated contract of two parties. Sometimes the Team will want to remove a particularly hard condition of satisfaction in order to feel confident that they can complete the Story within the sprint. Flexible Stories are sometimes able to slip into a sprint when rigid Stories cannot.

In ScrumMaster training I attended earlier this year, the INVEST acronym was used to describe the principles of good User Stories. INVEST is an acronym that stands for Independent, Negotiable, Valuable, Estimable, Sized appropriately, and Testable. Remember the INVEST acronym when writing your User Stories and your Stories will be meaningful contributions to completing your project.