User story anatomy: who, what, why and the conversation

"The system shall allow users to manage bookings." That sentence is a requirement, and it is useless. Manage how? Which users? Why does it matter? A user story is an attempt to keep the useful part of a requirement, the need behind it, while leaving the detail to be worked out with the people who will build it.

Where stories come from

The Agile Alliance traces user stories to Extreme Programming, where they were described as one of the building blocks of planning and meant to encourage a more informal, conversational way of capturing requirements than long written specifications. Each story is typically written as a brief sentence on an index card or sticky note, a reminder of its value, and the detail is deliberately left until the story is nearly ready to be built: a story due next Sprint should be better understood than one that will not be built until the next release.

A well-known summary of the idea is three words: card, conversation and confirmation. The card is the short written description, whether on paper or in a tool. The conversation is where understanding grows: the user's goal, the trade-offs, the edge cases. The confirmation is how the team will know the story is done. A story that has only the first of these is a note. A story that has all three is a unit of work.

The three questions

The common template, "As a [who], I want [what], so that [why]", gives a story three parts.

• Who. The person or system that benefits. "As a user" is almost always too vague. A parent, a tutor, a regional manager and an administrator want different things.
• What. The capability they need, described from their side, not as a screen or a database change.
• Why. The benefit, and the part most often left out. The "so that" clause provides the context that helps get from what the customer thinks they want to what they actually need.

Compare two versions of the same story.

As a user, I want to cancel bookings.

As a parent, I want to cancel a lesson up to 24 hours before it starts, so that I am not charged for a lesson my child cannot attend.

The second names a person, a limit and a reason. It also raises useful questions straight away. What happens inside 24 hours? Is the refund full? Does the tutor get paid? That is the conversation starting, which is the entire purpose.

The SBOK® Guide uses a very similar template, with "I should be able to" in place of "I want", and says a story describes three things about a requirement: who, what and why. The words differ, but the structure is the same.

What makes a story good: INVEST

The INVEST mnemonic, which the Agile Alliance describes as capturing the assumptions behind a good story, is the best checklist there is.

• Independent. Stories can be delivered in any order. Real dependencies exist, but each one you remove makes ordering easier.
• Negotiable. The details are worked out between the people building it and the person who needs it, not fixed in advance.
• Valuable. A customer or user would see the result as valuable. "Create the database tables" is a task, not a story.
• Estimable. The Developers can size it. If they cannot, there is something they do not understand yet, and that is a finding worth acting on.
• Small. Small enough that several fit in one Sprint. The Scrum Guide describes items that can be Done by the team within one Sprint as ready for selection at Sprint Planning.
• Testable. You can say what "works" means. This is where acceptance criteria come in.

Not every story will score perfectly on all six, and that is fine. The point is to know which one a particular story is failing.

Level of detail

The most common error is writing too much, too early. A story that has five paragraphs of fields and validation rules is a specification wearing a story's clothes, and it will be out of date before anyone builds it. Detail belongs near the time of building. A story near the top of the backlog needs enough shape to be sized and discussed. A story near the bottom can be a single line.

The opposite error is real too: a story so thin that nobody can estimate it. The test is practical. If the Developers can ask good questions and size it, it has enough.

Splitting

Stories at the top of the backlog need to be small enough to finish in a Sprint. Large ones, often called epics, are split as they approach the top. A useful rule of thumb is to split by outcome, not by layer. "Cancel a booking" can become "cancel a booking and see it disappear from my list", then "cancel with a refund", then "cancel with a partial refund inside the limit". Each slice is usable, which a split into "database", "interface" and "payment code" never is. This work is part of backlog refinement.

A quick way to test a story

Before a story goes into planning, read it aloud and ask four questions. Who is this for? What will they be able to do that they could not before? How will we know it works? Could we finish it, with the other stories, in a Sprint? If the answers come quickly and agree, the story is ready enough. If they produce a long pause, that pause is the most useful output of the exercise, because it shows what the team has yet to talk about.

Mistakes to avoid

• The story is a task in disguise. "As a developer, I want to upgrade the framework" is sometimes unavoidable, but if most of your backlog reads this way, the Product Owner is not describing value.
• The "so that" is missing, or restates the "what". "So that I can cancel my booking" tells nobody anything.
• The story is written for the team, not by the team. Stories are most useful when the people who will build them take part in the conversation.
• The template is treated as mandatory. Mountain Goat Software's guide to user stories says plainly that the form matters less than whether the team can have the right conversation, and that some items read better without it.
• Acceptance is left to the end. If nobody has said what "done" means for the story before the Sprint starts, the Sprint Review is where you find out you disagree.

How to practise it

Writing a good story is mostly a matter of noticing what is vague. In the simulator the team drafts stories with acceptance criteria and the Scrum Master checks them before they are accepted, and some of the drafts hide defects.