User Story Heuristics: Understanding Agile Requirements

[article]
Summary:
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 Comments

4 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?

Regards,

Dan

 

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.