User Story Heuristics: Understanding Agile Requirements

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. This article details what user stories are (and what they are not).

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.

User Comments

Simon Rigler's picture

Great article Allan! You have struck a chord with how I feel about one of my projects. We are good at getting the placeholders (User Stories) workjed out and agreed upon, but it's that next level down - "the work to be done" as you say - which we need to improve upon in our technique and processes. Could you please, please write an article on this next?!

Simon Rigler


July 10, 2015 - 5:30am
Allan Kelly's picture

I thought I left a comment yesterday but its not here, odd.

Simon - would you care to say some more about the your question - mail me direct if you like.

The next piece is already in the machine so it might be a few weeks before I can properly address your request


July 14, 2015 - 12:02pm
Dan Boot's picture

Hi Allan,

Not sure if you remember me - you and Seb delivered agile training with a company I used to work for. I would also be really interested in the answer to Simon's question i.e. Once you've decided which "token" or user story to work on how is the detail of the user story conveyed to the devs/testers/et al.? What I suppose I'm trying to ask is - other than having a conversation would you imagine the BA/PO using other requirements techniques e.g. process models, use cases, wireframes to help support and claryfy the requirements?




August 4, 2015 - 1:03pm
Allan Kelly's picture

Dan - sure I remember you, and I know you've moved. Feel free to carry on this conversation direcly, my email address is obvious.

Now, how is the detailed conveyed.... usually by conversation.

The Product Owner/BA is the one who knows (or should know) how it needs to be. If it helps them to use process models, use cases or wireframs then use them. I see process modes and use cases as primarily analysis tools to help understand what is needed. Wireframes are slightly different because they are descriptions of the solution.

If presenting any of these things to the coders and testers helps then use them to support the conversation.

In part 4 of this series I describe task break down. This can be a useful way to keep the conversation going and consider details.

Part 5 is going to look at acceptance criteria, these too can help explain and extend the conversation.

Does that help? - let me know if I need to say more





August 5, 2015 - 4:17am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.