User Story Heuristics: Understanding Agile Requirements

User stories are probably the most widely used requirements technique in the agile world. This humble little who-what-why template was originally devised in 2001 by a team at Connextra in London, and it quickly gained widespread adoption:

As a someone
I want to do something
So that some result or benefit

Simple, really.

Many traditional requirements engineering and elicitation techniques are still valid in agile; it’s just the results don’t end up in a big document. Agile emphasizes just-in-time requirements rather than upfront preparation. The requirements person—be it the product owner, business analyst, product manager, or someone else—embodies the understanding of what is needed, and the user story represents the work that needs doing.

User stories have three attributes that fit well within agile:

• Lightweight: They don’t impose a lot of (upfront) costs on the team
• Easy to understand: You don’t need a five-day course to understand them
• Easy to share: Objectives are simple to communicate between the technical team and customers

It is the third of these attributes that makes user stories my preferred choice: they are inclusive. Customers can engage with stories. Many other techniques are superior in terms of analysis, rigor, and completeness. But these advantages come at a significant cost: They create a barrier between those skilled in the approach (technical experts) and those who are not (customers.) Because user stories are so simple, they help create common understanding.

A Placeholder for a Conversation

User stories are not, and should not be, complete requirements for software development. People call user stories a placeholder for a conversation, meaning the stories capture the essence of what is wanted, but they don’t contain the detail. When the time comes to do the work, there will be a discussion about what the stories need.

I think of stories as tokens for work to be done. They are not the work itself—that has not yet been defined—but they represent the work. These tokens can be prioritized, shuffled, refined, changed, split, and more. When a token rises to the top of the pile, it is time to work on the story.

The first job is to understand what the job is. Conversations about stories are not just between the requirements person and the coder. If the team contains software testers, include them, too. Indeed, having the tester in the conversation is more important than having the coder.

User stories themselves need not be perfect; in fact, the biggest mistake with user stories is trying to make them exactly that. They should be transitory and short-lived: a means to an end, not the end itself.

When it is time to have that conversation, try conducting it in person instead of through documentation. Written documents are more expensive than commonly recognized. Each document costs twice: writing time plus reading time. There are other more effective, more efficient forms of communication.

Having a conversation about a piece of work can be cheaper, timelier, and more effective than communicating via documents or email. In a conversation, people can ask questions, skip a section, or discuss a section in depth. So, save time (and money) by talking instead of writing documents.

Each Story Has Business Benefit

Each story should have some business value. The story may earn revenue, reduce costs, attract customers, make employees more effective, or deliver value in some other way. Putting a value on a story may require sales projections or an understanding of time savings. Ideally, I’d like to see a financial amount on each story—a hard dollar number that states the monetary value of the story. Having a financial value on a story makes prioritization easy.

I encourage teams to estimate story value in the same way some teams estimate work effort: with poker cards. Sometimes I’ll invoke the TV show Shark Tank or Dragon’s Den and have one team pitch its stories to another team. The other team plays investors and tries to assign value to the story.

However, putting a number value on a story can be hard, and not just because estimating a value can be hard. Sometimes stories aren’t quantifiable because they deliver something intangible, or because one story delivers a small piece of something much bigger. Some stories improve the user experience, some improve quality, and others are given as unquestionable mandates: “This story simply has to be done.”

Even if a story doesn’t have a quantifiable benefit, it should have some statement of benefit. I like to see at least a short sentence with the story, saying something like:

“Fred says this story is beneficial because …”

Business benefit is anything that helps the business and business representatives accept the story as useful. Benefitd might include learning and knowledge creation, enquiries into the market, and demonstrating commitment to a single stakeholder.

Someone, somewhere wants the story, and they should be able to express the reason as a benefit. If there is no identifiable benefit, then why build it?

User stories are far from perfect. But if I may borrow from Winston Churchill, I have come to believe that user stories are the worst requirements technique, except for all the rest.