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.
I recently pushed the stakeholders to write user stories for the first time in the history of the company to help fill out our product backlog for a project. Overall it was touch and go – not bad for a first jaunt but lots of room to improve.
We used the template you prescribe and it worked very well for us. We found several benefits to having each story contain the user role, the feature, and the value statement. The most immediate benefit was that writing acceptance tests was cake. It also helped focus our story-writing workshops because we could focus on a single user role and storystorm for 10-minute sessions, then collate our stories and start again.
Hi Beefarino–
I’m always very impressed by stories like yours where someone says they committed to writing all three parts of that template and how beneficial it was. I spoke with someone during one of my classes recently and he told how he led an effort to identify a new product in his company. They wrote user stories and decided to include the value statement in each (“so that…”). He reported that this was instrumental in the business plan his team created being accepted. He said that the company was so impressed that they funded the creation of a new business unit to pursue the produce they’d described with user stories, each including the so-that clause to emphasize why each was important.
-Mike
This template feels like a very good idea. It seems to work well when creating stories for new features and functionalities. How about bugs and such? Could we also use this template for bugs so that backlog items would be consistent?
E.g. if login page throws an exception when user writes password longer then 10 characters could we write a story “As a user, I want to write a password as long as 64 characters so that password is secure enough”. It doesn’t express the fact that the story is for a bug and that the current implementation doesn’t work with long passwords.
Maybe you have already written about this in your book as it contains chapter called “Stories for Bugs”
I’m planning to read it (User Stories Applied) in the next few months.
Hi Tommi–
First, from a user’s perspective there really isn’t any difference between a bug and a feature. To convince yourself of that, imagine a tech support line where when you call you are told, “Press 1 if it’s a bug or press 2 to request a new feature.” From a user perspective it doesn’t matter–the system doesn’t do something I want it to do.
More specifically to answer your question, though: In general there are a couple of ways to handle bugs. Often there are are lots of tiny bugs. These don’t feel worth estimating and if I go into the code to fix one of them I might as well just fix a bunch of the bugs in that subsystem. When working with physical index cards I tend to stack those bugs together, put a blank card on top, and rubber band them together. On the top card I may write a user story such as “As a user, I want all the medium, high and critical bugs in the search screen fixed.” More simply, I do admit to sometimes just writing “Search screen bugs” on the blank index card. In either event, that collection of bugs is really what I’d call a “theme.” It is a collection of related product backlog items.
Alternatively, you could actually write each defect using the As a user, I want… so that… template. Generally, though, for the small, highly specific bugs this is more work than it’s worth. If the bug is very specific, write a specific bug title just as conventional best practice would have us do.
-Mike
Great stuff. Always keeping value to an actor in the user story forces us to consider the use of it, allows us to remember it and to discuss it in natural terms and has significant benefits.
Further, following this format is an exceptional best practice towards executable requirements and a domain specific language. Deriving acceptance of the user story automatically from the code that describes it is a best practice that is showing huge benefits to the customers I work with that implement them.
Great post, Mike.
Do your users’ stories become part of an executable acceptance test suite, something like the Rspec StoryRunner, or do you use them only as a way to gather and prioritise requirements?
I’m a big fan of TDD/BDD, but I haven’t yet seen a compelling case for going to the extra effort of creating executable stories. So, I’d be very interested to hear your thoughts.
David
Hi David–
To me there is a sequence through which features move as they become progressively refined by the team (which includes the product owner). We start with “epics,” which are just big user stories. These are placeholders largely for something we want a bit further off in time. Soon the epic is ripped up and replaced by multiple smaller user stories. These typically are small enough to fit in a sprint. If one isn’t, it will be left alone for a sprint or two and then replaced by 2-3 more that are small enough.
My fantasy is then that the product owner stays up all night the night before sprint planning. She selects the user stories that the team is likely to work on and turns each story over and writes the “conditions of satisfaction” (COS) on the back of each. That way when the team comes into the planning meeting the next day they can see her expectations in the form of COS. I don’t really want the product owner to stay up all night doing this; that’s just my way of saying I want it done just in time. More realistically, the product owner writes most COS a couple of days ahead, some are figured out during the planning meeting, and occasionally some are figured out right after the planning meeting.
The COS aren’t executable tests but they do say what should be tested at a high level. Th next level in the progressive refinement is to create tests with something like FitNesse (still one of my favorites). Tests at that level become more specification by example than executable specifications.
[...] les 3 raisons pour lesquelles il préconise de décomposer les user stories sous forme de phrase “En tant que <role>, je veux <but>, pour que <raison>” (la raison est optionnelle) [...]
Hi,
I work with a team which is mostly involved with bug fixes & the bugs which may be found as a part of testing. Also the other team that I work with doesn’t have users-as in clients. That system has a consumer system and interacts with APIs. I am not sure if this format would work for such scenarios. If I try writing stories using this format, the main part of the story would go towards the end, which is not very desirable.
Ex: A bug is reported where the date associated with data for the reports is one day ahead due to time zone issues.
I write the story as:
Incorrect Date in Reports: The date associated with the data in the reports is one day ahead due to time zone issues.
If I use the ‘As a’ format, how would I write the story.
As a user, I would like to see data for the same day in my reports as this is important for right monitoring ?
This doesn’t give any idea about the main problem.
Please help me out with such scenarios so that I can also use a standardised format for my stories.
Hi Ketki–
If bugs are coming into a bug tracking system I usually just collect them and fix them in batch mode. For planning purposes I may label them with “bugs in the search system” or “As a user I want the search system bugs fixed.” But you’re right that this doesn’t add much.
There is still probably value in the template if you think harder about your users. I often write sample user stories with “as a user…” but hopefully you have better insights into your users and can use more descriptive roles. For example, one system I worked on for awhile had Customer Service Reps (CSR), account holders, and others. We could write “As a CSR I want…” and “As an account holder, I want…” That did tell us valuable information. In your case it would tell you who the bug is impacting, which probably is an important part of the deciding how to prioritize the bug / user story.
Also, if you put the stories in a format like in the Excel image shown above, someone reading your backlog can easily only glance at the user role column focusing most of their attention on the more important other columns.
I’m a relatively new product owner at a company that is moving quickly in adopting agile practices. On my newest project, we started to use user stories to create the product backlog. I must admit, things were a mess at first. I had huge stories that in no way could be completed in a single sprint. Beyond that, my “users” really didn’t care too much about the stories. You see, this project really involves systems talking to each other and the end user’s benefit is not clearly defined (of course there are some). Lastly, while I love the user story template you advocate, the “so that” in some cases seems so obvious that I feel silly writing it. Your thoughts?
Hi Eric–
I definitely wouldn’t use a so-that clause when it seems silly. An example I give is for a mythical travel website: “As a user I can make a hotel reservation.” The “so that I have a place to sleep” is pretty obvious. I don’t write it. But I’ve had many people tell me they do; they treat it as mandatory to help make sure the value is always obvious. I do find that when we work with smaller user stories I am more likely to add the so-that clause. It’s on the big epics that the value is sometimes obvious and we can go without it.
It’s OK to write stories using the other systems as users. This is where I prefer the use-case term “actor.” But we can write, “As the payment verification system, I want to receive all data as well-formed XML.”
Jason–
It sounds like you have two problems going on:
1) How to write stories when you just want the save behavior to persist over a hardware or infrastructure change. I think what you’ve written is fine. If you have a theme (a collection of stories) that we all know are about “get the old features working again after the hardware change” then what you have is fine. If you want to be more explicit but verbose you can write stories like “as a user, I can upload a file to my website even after the May hardware upgrade” or something like that. If you’re working on some change-related user stories and some “regular” ones that’s a better approach.
2) You’ve got some stories that are too big. I’ve written elsewhere with advice about splitting stories. This is indeed one of the harder things for teams to get good at when first starting.
We’re in the middle of an infrastructure migration that doesn’t require any ‘user’ functions to change, but code needs to be changed in order to support the new hardware. I’m confused with respect to how to write stories for something like this. For example, this would be an original story for our product: “as a user, I can upload a file to my website”.
Now that functionality isn’t changing, but config changes are required for the new system. We all agreed on a set of user stories for the required changes and now the team is changing their mind saying the stories are either too big or too small. I’m relatively new to Agile/Scrum and am not sure how to write stories for this type of thing since no functionality is being changed.
It certainly does help. After reading about this in your Effective User Stories paper we started using this structure for user stories in the team. We found that it was a great way of removing ambiguity from the feature/requirement and this was evident in the planning poker sessions as we seemed to reach consensus quicker. It also helped to identify details up front that we wouldn’t otherwise think of.
The main feedback I got using this methodology is that first it greatly helped generating a discussion in the team. Putting stories into context helped the entire team understand what the story is aiming at which is the key to generating a discussion. Our Sprint Planning meetings are much more lively now – everybody jumps in and participates!
Output:
1. discussion fosters team dynamics: everybody feels listened, better energy generally in the team
2. discussion makes the product more complete: everybody is adding stories the Product Owner didn’t think about
3. discussion clarifies the scope: developers know what they should develop (and what they should not), QA developers know what to test
Hi Nathan–
I think you’re exactly right. The template really helps generate discussion. I find the same thing to be true of estimating with Planning Poker. So when teams use both, they get two excellent chances to progressively refine their understanding of the user story.
[...] Cohn, whom I’ve cited before on the topic of user stories, provides insight on a format for articulating user stories that he has found to work well. I advocate writing user stories in the form of “As a <type of [...]
Mike
The user story template is far more than a software tool. In my wanderings, I have found it to be a very successful tool at the far end of the Product Life cycle. here it allows key players to discuss their perception of the vision from different perspectives they have without having to invest a personal /political stake in an position.
Sounds kinda weasle-word doesn’t it? Not really At the point you are creating an expression from the vision statement, the chances of you being right are infinitely. Speaking “AS” a type of person/role/persona/ system/animal/mineral/vegetable things get brought out and then chewed on. Little by little a bunch of consensus points fall together and you have the basics of a description to express the vision statement.
Sometimes person in a role does not have an expectation from a specific action but participates in an overall transaction from which he benefits. In such cases, it seems odd to use “I want”. I have sometimes instead used “I need” to make the intention clear. Does it make sense to do so?
Hi Prabhakar–
Yes, it’s perfectly fine to write “…I need…” instead of “…I want…” I don’t have a strong preference personally but many people find one better than the others.
Hi Mike,
I’ve been using this template for years and, as a product owner, I force customers to add the “so that†fragment. One of the reasons is that it often helps identifying the meaning and relative importance of a story even long after it has been written. The template gives you a “who†(As ) a “what†(I), and a burning “why†().
But there is another, much more important aspect that I would like to offer: the “so that†fragment helps identify potential alternative solutions.
I did a presentation recently where I explained that often customers have “wants†but often have difficulty to express their actual needs: they may ask for a “longer antenna†while they need a “better receptionâ€. Once the real need is identified, it is much easier to find potentially cheaper or more effective alternatives (a “better reception†can be obtained in different ways). What happens then is that we move from a “what†(customer expressed intention) and “how†(developer’s way to implement the requirement) to “what ifâ€, an entire world of possibilities.
Hi Claudio–
That is a excellent description of why to include the “so that” clause. I’m just not a “this is *required*” type of guy, which is why I don’t require it. But I totally see why so many people do and I think I secretly want to require it. Thanks.
Thank you, Mike! I understand your personal dilemma.
I’m usually not prescriptive either. Applying rules blindly often preclude further experimentation, which is never a good thing. In my little experience however, this convention proved (on the field) to be simple to adopt and extremely effective. I also never found any resistance to adopt it, particularly once the reasons and benefits are clarified among stakeholders!
Hmmm… I really had issues with the As-a…/I-want-to template–probably because of the boilerplate in it. However, the tabular format in this post made me realize that this is not really far away from a well-written actor-goal statement or a use-case title. (I’m a fan of Alistair Cockburn’s approach to _effective_ use-case writing…) Interestingly, the so-that part provides insight into the user’s motivation for achieving the immediate objective (the user goal in use-case speak).
So, thanks for that. I’ll have to think about this some more…
Cheers,
Oliver
I am really struggling with internal system processes, which are not visible to end-users. For instance a web page, which takes about 6-8 ideal working weeks to create. And 80% of it is absolutely required to give the user some useful information. How should those be handled?
Or another case, where we have an internal process consisting of 5 steps, now the customer wants to change the order of the steps ?! So again, there is no effect on the actual user of the system (the end-user).
Piotr
Hi Piotr–
You may want to see the post on this blog called Writing User Stories for Back-End Systems. I think it will address some of your concerns about writing stories for that type of system.
re: the story that the user won’t see but the customer wants: I’ve written many times in various places that a “user” story can be valuable to someone other than a user. In this case the story is valuable to the customer. Write it “As the customer…” or “As the product owner…”
re: the web page that will take 8 ideal weeks to create. My Agile Estimating and Planning book has advice on splitting user stories, but here’s one tip that apply in this case. In those 8 weeks there must be a time when the developer wants to say to his coworkers something like, “I made great progress the last few days. I can’t wait to show you the…” If you truly have a complex user story (not just a compound user story, which is easily split) then work will need to occur over multiple iterations. Find those points where tangible progress has been made. Pre-identify a few of those and select a subset to complete each sprint.
I like this template a lot for all the reasons listed and more. I really like the “so that…” portion and I don’t think it should be optional at all. The underlying motivation for wanting a feature can often lead to something much better than what the user thought they wanted, but it’s important to understand the user’s motivation in wanting the feature in the first place. You can mentally insert the Henry Ford / faster horse quote here if you like.
[...] User Stories erfahren möchte, dem seien die folgenden Ressourcen ans Herz gelegt: – Artikel Advantages of the “As a user, I want†user story template. – Powerpoint Slides von Mike Cohn “Effective User Stories for Agile [...]
[...] I was just reading Elizabeth Koegh’s blog on a preferred syntax that I’ve blogged here. So, I thought what does this look like with understanding StoryQ – a bdd framework? Is it same-same-but-different? I found the newer syntax easier to write and harder to review. Compare this with Mike Cohn’s argument. [...]
Hi Mike,
We’ve been using this template for several months now, but I only recently came across an issue whereby some team members expect the ‘As a…’ portion of the story to indicate story security – i.e. assuming that only users listed in the ‘As a…’ should be able to use the ‘I want…’ functionality.
I would have expected to address any restrictions of this nature through acceptance criteria, if for no other reason than to ensure every story boundary is clearly expressed as a testable restriction.
Is this is a common assumption / expectation around the ‘As a…’ part of the story? Should I need to define how this field will be used in my project’s definition of ‘done’?
Hi Marion–
I’ve never seen a case where a team went so far as to act on the assumption that the user role in story was the only one who could do that action. I have, however, had teams ask the question often. I guess, though, they asked earlier enough that I could clarify this before they coded it that way.
Ron Jeffries has a great article saying that user stories comprise a Card, a Conversation, and Confirmation. The Conversation is the protection that should really clarify things when a programmer misinterprets a role in a story to be a security restriction.
I usually coach teams to write a story using the user who is most descriptive of the action being performed. And to think of user roles as existing in a hierarchy with generic “user” at the top of the hierarchy. All stories could be written “as a user…” but it is often more informative to write the story with the specific user most likely to perform the action. A common example would be on a travel website and “As a vacation traveler, I can see photos of the insides of hotel bedrooms so that I can pick the best one for me.” A business traveler (another role) could look at those photos but it’s more likely to be done more often by a vacation traveler. So, we write the story with that user in mind.
How can I write the stories of the functionality that are made by the system automatically.. Example for a ticket reservation system, 30 minute before the session starts system drops the reservation.. how can i write this as a user story template..is it ok to write like this
system drops the reservation 30 mi. before the session starts????
Hi Halil–
First, it is of course OK to write a user story or product backlog any way you find beneficial. So, I’d find nothing wrong with “the system drops the reservation thirty minutes before an event starts.”
On the other hand, I think that writing it from a user’s perspective can often make the value of this more apparent. I’d suggest something like:
“As a last-minute ticket buyer, I want all unclaimed tickets released thirty minutes prior to the event so that I can buy tickets.”
It is beneficial to express product backlog items in terms of a user’s goals whenever possible rather than as attributes of the system itself.
[...] David Chelimsky no Rails Summit Latin America e David Anderson no Falando em Agile 2008 apresentaram um formato de história ligeiramente diferente do formato clássico proposto por Mike Cohn. [...]
Hi Mike,
I’m thinking of using something like ’system level stories’ as something that the whole project signs up to.
Just been reading your ‘User stories applied’ book. Excellent stuff, thanks.
I’m the Chief Test Architect for a number of large middleware products based in Hursley in the UK.
Couple of challenges we are having at the moment, firstly the ‘indivisible user story’ – you know the ones that ‘can’t possibly be made any smaller’ and secondly how system test fits with user stories. I read your section on constraints with interest as I think this goes someway to recognizing their importance to the project over all. I’m not sure ‘constraints’ is the best word to use as it has negative connotations to me (or is that me being a test victim
I’ll keep blogging my thoughts on http://www.testingblues.com
Thanks
Jon
[...] Mike Cohn wrote an excellent article on the advantages of using user stories for requirements for which I did a brief synopsis a while back that can be found here. In a separate article, Cohn also provides a useful format for capturing user stories. [...]
Hi Mike
I have your book and find it very interesting. I would like your insight on what a requirement elicitation workshop would look like if the end result will be to capture all the user stories from the stakeholders.
What do you change in your facilitation approach and what to focus on. Do you need to educate the stakeholders on what a user story is ( especially if they are already used to Use cases?)
Thanks
Hi Risa–
Yes, I would start a user story-writing workshop with a brief discussion of what a user story is. I usually spend no more than five minutes on that–it’s just not that hard to get the idea across. Any hard questions will come up as they write them. I usually post the “As a <type of user>, I want <some goal> so that <some reason>” template on a a big white board so everyone remembers it. Then start by identifying some common user types you’ll use in your stories. Look back in User Stories Applied and you’ll see more details there on running this type of session.
Mike, how do use cases relate to user stories? I love the thinking involved with walking through the steps a user should take and how to handle alternate scenarios as well as defining post conditions. Are use cases in Scrum artifacts that a team may or may not create during a Sprint to help it analyze a problem?
Hi Steve–
The question of how user stories compare to use cases is covered in this article and in chapter twelve of my User Stories Applied book.
Mike,
I believe that we can improve on the “as a user” format to a “what I want” format.
I’d love to hear your comments. Here is the blog article:
http://confessionsofanagilecoach.blogspot.com/2009/01/good-stories-have-great-titles.html
I tried to apply this template using a sample application and it seems to make the initial thoughts very clear. the importance of forcing the stories to be short seems to be to elicit the features at the lowest level of granularity.
However, I am lost on one point: where do I write/document/note system constraints. For example one story is:
As a bidder I would like to submit a bid so that I can be the bidder with the best price.
This itself is not a problem. The issue is about the bidder bidding for multiple auctions concurrently. The decision on whether this is allowed or not should ideally be made early on because it seems to impact the design.
So the question is, how do I document a constraint which says:
The bidder is allowed to participate in one auction at a time. (or the other way around: the bidder is allowed to participate in more than one auctions concurrently).
Hi Kinjal–
Why not use, “As a bidder, I can only bid on one auction at a time”? You could add a reason–perhaps “so that I am forced to choose carefully” or “so that I cannot corner the market on whatever_it_is.”
The point of the story is to make this requirement known, remembered and discussed. Seeing something like that in the product backlog would seem to do that for me.
[...] if you’re creating user stories and follow the standard story template there won’t be anything to revise. But with use cases and functional specifications there is [...]
[...] templates are also one of the guidelines mentioned (page 81). Mike’s blog has further reading on the topic. For projects just beginning the agile process, its probably a [...]
Hello Mike,
How to cope with user wishes (utterances by clients) in the form:
“As a scholar I want to be impressed by the website”.?
These wishes are not functional in nature, nor are they exact/ testable. They are concerned with the look&feel, experience (-interaction?) design. This is good input for our graphics team members (and a bit for the interaction designer) and the customer values these. Looks like a non functional requirement to me and not a user story(?).
So my question, How to deal with these kind of wishes, which I think can not be written into the template user story?
(or should it be written in the form: “as a scholar I browse through projects and I want to be impressed”)
Hi Jerome–
I have a separate blog post specifically covering non-functional requirements. It’s at http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
Thx Mike, all interesting material, and answers my questions!
Mike,
When I started with Agile several years ago, I randomly chose FDD as my process guide and read that book first. I had to start somewhere and thought that methodology most appealed to my needs and preferences. When I lead the first agile planning and domain modeling session with the company executives, I was amazed by what the FDD template ” ” provided in regards to concise, meaningful, actionable stories (features) that I could then plan development around. When the rest of the company jumped on the agile bandwagon, the IT leadership brought in an XP-hybrid agile evangelist to introduce “agile” to the corporate management and select IT resources. In the one day session, the speaker did not cover story templates. For the next couple of years, “good story writing” was probably the single most difficult aspect of agile adoption. Recently, I rediscovered your book and this proposed template and its helped tremendously with clearly communicating not only how to write a story, but what a story is. By requiring that each story adhere to this template, you guarantee that the story author answers the “who, what and why” while you also prevent verbosity. I am amazed by how much communication is enhanced by having this template drive the authorship of user stories. thanks as always