Keeping the User in User Stories

30 January 2014

If you have read my books, seen me speak at a conference, or taken one of my Scrum training classes, you know that I'm a big proponent of writing user stories in the following format:
“As a <type of user>, I want <some goal or feature> so that <some reason or outcome>.”

I want to share two reasons why I remain convinced that this template is the best way to write a user story.  

Two Reasons to Use the Template

The first reason I use the template is that something special happens when requirements are framed in the first person. Saying “As a such-and-such, I want …” makes it personal, helping you identify with your users and their needs. By telling users' stories, your product owner is giving you a glimpse into your users' minds, which will enable you to fill the need more accurately and specifically.

The second reason I believe the template is a great way to frame a user story is that having all your stories structured in a similar way helps the product owner prioritize. Imagine a product backlog that contains only a list of to-do items:
  • Fix exception handling
  • Let users make reservations
  • Users want to see photos
  • Show room size options
Without the template information, the product owner has to work harder to understand what the feature is, who benefits from it, and what the value of it is. With the template, the product owner is able to see at a glance the intended user, the feature, and the reason why it's important.

Common Complaints

Some people complain that writing stories using the template actually suppresses the information content of the story because there is so much boilerplate in the text. If you find that true, then you might want to display the boilerplate in grayed text with the unique parts in black. You can also create a backlog in Excel that uses column headings to filter out the common text. For more on why I believe the boilerplate is essential for understanding the story, check out my 2008 blog post, “Advantages of the “As a user, I want” user story template."

Others worry they don't know enough about their systems yet to figure out who the users are. If that describes your situation, I recommend you find out about your real customers. Read Eric Ries' Lean Startup for some guidance into finding out about your customers when it seems impossible. I firmly believe that you can't create the right system until you know at least a little about who you are building it for.

I like the user story template. It's personal, its practical, and it works. For now, and probably a long time to come, I'll be sticking with the, “As a <type of user>, I want <some goal> so that <some reason>” template. I hope I've given you some compelling reasons to try it too.

Article Rating

Current rating: 5 (3 ratings)
Comments
Gene Gendel
I would not want to repeat the fundamentals of user story writing (what acceptance criteria are and what they are not, sizing, splitting, combining, etc) or stressing the fact that scrum does not prohibit supportive documentation, it just forgives if we are not using it if it is not needed (wasteful) and NOT using it as a substitution to conversation… - this would be way too basic and I am sure every is aware of these basic principles.
But I would like to stress a few things:
Yes, writing user stories in user-centric tone (not system centric), stating a single important action in pursuit of a single most important benefit – is important. This helps keeping in sight business value of each story – something that has economic consequences. Many POs become too sloppy and self-forgiving, and leave “so that” clause out or write it in a very vague tone, just to “fill in the black” – bad, bad… As a story reader, who may know nothing about a product, I want to read a story and at a glance know WHO wants WHAT and, no less importantly, WHY. The basic format really helps with this.
Further, user-centric story writing, if properly superseded by user role modelling, can actually create a great holistic view of how big is the scope of requirements for each identified user. Many other techniques and mechanics can be used to derive benefit from having stories written in this simple format (I much as I personally consider excessive “templatization” wasteful, this is not the case here)
I understand the notion of <constraints> or <exceptions> or <NFRs>. Yes, often times there is a need for them. So again, scrum is not prescriptively-preventive to these. It is the question of ‘how’ we do it in the most effective (scalable) way. Depending of the uniqueness of the above <>s, we may want to put them as separate sections on individual stories themselves OR extract them from individuals stories and keep them elsewhere. Where? Well…you may keep them at “technical stories” that sit upstream (are predecessors) to your user stories. {{{Here, it is worth nothing that I am a strong advocate of NOT abusing “technical story” but rather using only it is absolutely needed.}}}
We may also keep overarching <>s at Epic level. If teams are disciplined in user story writing techniques and always maintain traceability between a stories and an overarching epics, then things could be pretty neat: teams may just consider <>s as “include requirements” for each story that sits below an Epic.
Last, but not least, if teams do test automation and use test tools (e.g. Cucumber) to execute test cases, proper user story structure helps a lot – it is so much easier to write test cases if user story writing is consistent. You can parameterize tested conditions much cleaner this way.
6/14/2014 10:43:08 AM

David Updike
John, I don;t want to speak for Mike but as the details emerge during your project according to your process you do need to put those details somewhere. You need to choose what is best for your team. It's hard to go over all the possibilities here but if you use Rally for instance you can put all of this in the virtual card, or you could put some if it in a different repository and point to it from the virtual card. If you are hard-boarding everything then write the Acceptance Criteria on the front of the card and important details on the back but I think no matter what you will need outside repositories to store some of these like mockups, comps, test cases, etc. and reference them form the Story Cards.
2/25/2014 1:27:50 PM

Leonhard Grugl
We also use this template and it has worked really well for over two years now. I frequently extend it a little to "..., while <constraints>.", so that this is also basically covered. For further detail, we use the feature to attach notes to our stories in the mindmapping tool we're using for our product backlog.
2/18/2014 8:15:06 AM

John Yost
Mike, I understand your rationale for the format, but where do you put all the detailed information that must accompany this overview statement, i.e. mockups, acceptance criteria, design constraints, etc.
2/13/2014 5:17:46 PM

Leave comment



 Security code