Get certified - Transform your world of work today

Close

Keeping the User in User Stories

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 (4 ratings)
Comments
Mike Cohn
Hi Deepak--

Thanks for your comments. I especially want to agree completely with "keeping the users in user stories."

While acknowledging that the ultimate goal of a story is usually a conversation, stories do get written down if only as a way of tracking them. And so, I've experimented with just about every way of writing a user story. I keep coming back to "As a (user), I (want) so that (reason)."

I think I keep coming back because that template--unlike many others--puts the user front and center. The first thing in a story written this way is the user. I know when I read a story written this way I instantly start to empathize with the user ("OK, I'm this type of user and I want to do...")

Thank you for stressing the importance of this for all of us.
11/2/2014 7:44:15 PM

Mike Cohn
Hi Gene--

Thanks for stressing those points. Each is vital. I especially like that you included a mention of testing.
11/2/2014 7:31:49 PM

Mike Cohn
Hi Leonhard--

I'm glad you've been successful with this template, too.

I often extend it as appropriate as well. For example, I'll commonly write something like "As a user *who has just completed a search*, I want to..." or something like that to provide additional context.
11/2/2014 7:30:31 PM

Mike Cohn
Hi John--

Sorry for the massive delay. The SA site never notified me about comments on this post. It's been notifying me of more recent comments so maybe it's a feature they added recently.

I think of stories as *pointers to requirements.* Ideally a story points just to a simple conversation. Many times that can be good enough. But, in more complex situations it isn't. In those cases, create one of the artifacts you list as appropriate.
11/2/2014 7:29:08 PM

Deepak Joshie
When as an owner I want to produce any product, what may be the motive behind that? Lots of motives…some for people (stakeholders, end users) and some definitely my personal!
I feel the nerves of the market, I sense the requirement.
And what I want as a response for my delivered product from the end users?
The end uses should have a feel of joy and of course, ease of working with it. I am sure all of us have came across, if not developed, softwares which had earned money for the owners but not earned satisfaction from the end users.
And there comes the significance of User stories- Putting ourselves in other’s shoes.
If we can not sense what an end user needs, how we can make a better solution?
This is why it is always better to have personas prior to writing stories or at least identification of user roles.
A simple user does not know the intrinsic of a software and that’s why we facilitate them to get the solution they need. User will not tell each and every requirement upfront and we will get these from them time to time. Expanding the template of user story will lead to the mindset what we had during waterfall model. Again expecting the perfection of getting all requirements in initial stage, which is quite impossible. This will lead to comprehensive documentation and contract negotiation rather than customer collaboration.

User stories are generally initiated by product owner and time to time constraints and other information, key points of discussions can be added by and scrum team members. In my view this is the essence of user story and it’s significance- Keeping the User(s) in user story.
10/12/2014 12:27:14 PM

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

 Security code

 

Newsletter Sign-Up

Subscribe