In my user stories book and in all my training and conference sessions on user stories I advocate writing user stories in the form of “As a <type of user>, I want <some goal> so that <some reason>.” While I consider the so-that clause optional, I really like this template.
At a recent conference, someone asked me why. Because I get that question fairly often I want to give three reasons why here:
Reason 1
Something significant and I’m tempted to say magical happens when requirements are put in the first person. Obviously by saying “As a such-and-such, I want….” you can see how the person’s mind goes instantly to imagining he or she is a such-and-such. As for the magic, Paul McCartney was interviewed and asked about why the Beatles songs were so amazingly popular. One of his responses was that their songs were among the first to use a lot of pronouns. Think about it: She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car, etc. His point was that these helped people more closely identify with the songs. I tried briefly to find a source for this interview tonight and the closest I found was this. The information in that reference fits my recollection of hearing McCartney says this during a radio interview in 1973 or 74 that I assume was recording when the Beatles were together.
Reason Two
Having a structure to the stories actually helps the product owner prioritize. If the product backlog is a jumble of things like Fix exception handing, Let users make reservations, Users want to see photos, Show room size options, and so on, the product owner has to work harder to understand what the feature is, who benefits from it, and what the value of it is.
Reason Three
I’ve heard an argument that writing stories with this template actually suppresses the information content of the story because there is so much boilerplate in the text. If you find that true then correct it in how you present the story. I’ve seen backlogs in Word that present the boilerplate in grayed text with the unique parts in black. I’ve created product backlogs in Excel that use column headings to filter out the common text. Look and you’ll see what I mean:
Seriously take a look at the image above before continuing….I’ll wait……Please, really look at it before reading further…..
OK, here’s how I bet you read the spreadsheet. I bet that as you read most of the rows you added in the “As a…”, “I want….” and “so that….” text, possibly even by looking at the heading as you read across each row. I’ve experimented by asking people and this is what most people do. If that text is unnecessary, why do we mentally mouth the words to ourselves or even glance at the heading while reading the row? Perhaps it’s not so non-essential after all.
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 for these and other reasons.
Hi Rusty–
Thanks for sharing your story. As much as part of me hates having templates for things, the “As a type of user, I want some goal so that some reason” template really helps.
[...] savaged @ 15:42 Behavioural Driven Development (BDD) is exciting to me. That’s becasue the Agile User-Story and Acceptance Criteria, actually become merged with the code-base itself. Bringing them to life, [...]
[...] Mike Cohn on user story writing http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template [...]
another column to hold ‘Confirmation’ to this template would have been very nice. I use this template and have added ‘Confirmation’ column to list ‘Sucess’ or ‘Fail’ conditions to satisfy the story
@ Mike Cohn
It is really impressive that you take the time to answer almost every question in the comments! Thank you. Big fan of your work.
Thanks, Sergio. I appreciate that. I really try to answer all the questions here.
[...] o padrão de stories sugerido por Mike Cohn (e também encorajado pelo próprio Dan North), nosso cenário poderia ser algo como: Title [...]
Hi Mike!
You wrote “While I consider the so-that clause optional”.
I totally disagree with that. Actually, I consider the “so-that” clause the most important part of a story, because this is the VALUE!
Why keeping a story on the backlog, if there is no value on it???
Great article man!
Cheers
Hi Nicolas–
I say that the so-that clause is optional for two reasons:
So, I usually offer the guideline that a good product backlog will be about 90% user stories and about 90% of those will have good, clear so-that clauses. (Since I’ll get asked: the 10% of the backlog that isn’t user stories is just stuff someone put on the product backlog that probably could be turned into a true user story but wasn’t worth it. For example, “Upgrade developer laptops to Windows 7″ would not bother me on a product backlog today but we certainly could use the template to write that if we wanted.)
Mike,
Highly informative blog to go through…
I am wondering how we can depict the dependencies/linkages between User Stories. Do you recommend having a kind of ‘Story Architecture’ before we start breaking down a requirement?
Hi Seetharamu–
The best thing is to leave the stories as large epics as long as possible. This keeps most dependencies within a single epic and so they aren’t a problem.
Other dependencies can exist and you can handle those by annotating the card the story is written on. I don’t bother annotating “natural dependencies”—if we assume that we will add widgets to the database before deleting them, I don’t annotate the delete story with “assumes adding widgets is done first.” Sometimes that natural assumption will be false but in probably 99% of all cases that just means some of the effort estimate moves directly from one story to the other.
As for a “story architecture” the way I think about this is really just as a Feature Breakdown Structure (epics at the top, smaller features below). Sometimes a mindmap is useful and there are good tools for this. Jeff Patton calls a similar approach a story map but he brings time into his maps. You may want to look at those. Personally, I leave time out in the early stages because it’s impossible to prioritize (correctly) without knowing the cost and when I’m writing stories I don’t yet know the cost of each.
[...] refined the template I use for writing user stories. I am still inspired by Mike Cohn and I used his template for user stories as a base for my own [...]
[...] and in the process usually teach Planning Poker. Planning Poker is a tool. The story template [ref] designed by Mike Cohn is a tool. Likewise, a talking stick in a stand up meeting, a timeline in [...]
[...] Langage Naturel… « Alors déjà Vincent, nous, franchement, quand on relit nos tests, on reconnait plus certaines choses… C’est quoi tous ces mots clés qui apparaissent dans nos tests après le passage des développeurs? Ca devient illisible! » Sandie AMOA. Et si, messieurs dames de l’AMOA, vous utilisiez le langage naturel? Si, chaque action de votre scénario de recette était une jolie phrase en français, sans tableau? Et si, vous aviez juste à utiliser ce formalisme simple (décrit par ailleurs par « M. SCRUM » ici): [...]
[...] month and what needs to be done that day to succeed per the defined goal. As Mike Cohn writes (http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template) a user story in Agile Software Development is often in the form of “As a <type of user>, I [...]
Mike,
Please can you give me the value behind epics and would you ue them as almost phases when you thing of PMBOK.
Epics are value because they support the idea of progressive refinement of the product backlog. Rather than investing in writing a fully detailed product backlog upfront, we write each part of the product backlog at the level of detail most appropriate. If we’re going to work on a part of the system soon, we write small stories. If we’re not going to work on it for awhile, we write epics.
We started with the “As a ___, I want to _____, so that I can _____” format for our stories. But after a while we realized that we were writing stories which didn’t emphasize the business value we wanted to deliver.
So now we’ve switched to “So that I can _______, as a ______, I want to _____” format where we now emphasize the business value over the specifics of what we want to do.