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.

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.

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.

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.

Hi Mike,
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’m thinking of using something like ‘system level stories’ as something that the whole project signs up to.
I’ll keep blogging my thoughts on www.testingblues.com
Thanks
Jon

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.

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

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.

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.

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:

-Sometimes the value is obvious. The value of the story “As a forgetful user, I can request a password reminder” is probably pretty apparent. If it’s not, the value will come out in the conversation to the perhaps 1-2% of team members who can’t figure out why we would want that feature.

-I’ve found that as a consultant I need to be careful in mandating things. If I mandate something, I am doing so for all companies with whom I work or for everyone who comes to one of my agile training classes or reads a book. That would be mandating things to a lot of people whose project context I don’t know! ;)</li>

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.

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.

Mike,

Some of my clients have run into trouble when using this template, especially when the is really an internal stakeholder of some sort.  In your User Stories book, you mention that a user story is valuable to a user OR purchaser of system.  Does it extend, then, that you can represent a “purchaser” in the formalized story template?

Scenario:  You work at a company that has a website that sells products.  Someone in marketing wants to display an ad for a complimentary product every time a user puts certain products in their cart.  You could write this where the “type of user” is the shopping user, but really, the person who wants the functionality is marketing.  So, is something like this valid?  Note that I’m extending the “purchaser” label to someone in marketing.

As the director of marketing, I want to suggest complimentary products(if they exist) when users put certain products in their cart, so that we can increase sales.

Scenario 2:  You work at a company that has a website that sells products.  Your website uses outside Company A to process payments.  Someone in the finance department has decided that using Company B would be better, because processing costs are lower and the other system is easier to use when processing refunds.  You could write this where the “type of user” is the shopping user, but really, the person who wants the functionality is the finance department.  So, is something like this valid?  Note that I’m extending the “purchaser” label to someone in finance.

As the finance channel manager, I want our site to use Company B to process payments so that we save money on transaction and refund(customer service) costs.

Obviously in the conversation and acceptance tests, the team would discuss how this impacts the end user, and would write acceptance tests that cover the end user/system interactions.

Is going down this road ok, or fraught with danger?

Hi Charles—
I see nothing wrong with these stories. This is where the use case term “actor” is better. A good user story can be about any stakeholder of the system. And the story can just as easily be something other than “want” as in “As a shopper, I am shown complementary products when I start to check out.”  Or, “As a user, I am forced to change my password every 90 days.” So not all stories need “want” in them.

I see no danger ahead with stories as you’ve described them above.

Thanks for the feedback, it is great to hear it from the horse’s mouth.  :-)

I’ve been on a tear lately trying to advocate to people that really, the “As a , I want , so that ” is not in and of itself a User Story.  It is a “description” of a User Story, and using the template is just *one* technique to represent the description. 

People focus so much effort on the description and too little on the acceptance tests and conversation(the other 2 components of a US), and really, it should be the opposite, IMO. 

Having said that, my experiences as a Scrum Coach may be skewed since I deal with teams that are mostly brand new to User Stories and Scrum. The good fight continues!

I’ll only make one other *very* minor comment.  When you re-wrote the complementary products description, we lost some information.  Both the primary stakeholder (marketing), and the for the story were lost(much of the benefit provided by the template, btw).  That may be important, or it may *not* be that important, but I felt it was worth noting.  Again, using the template is just *one* way to represent the US description.

Correction:
> Both the primary stakeholder (marketing), and the for the story

should read:
Both the primary stakeholder (marketing), and the *reason* for the story

I gotta say, Mike, looking at your website, and especially this page:
http://www.mountaingoatsoftware.com/topics/user-stories

It seems like you also put a lot of emphasis on the description and almost no emphasis on the acceptance tests (aka COS).  That seems *very* unfortunate to me.
In fairness, you do put good emphasis on the conversation, though.  Why doe COS get no love on your User Stories home page?

Fair point. I will rectify that when I have time. (It won’t be any time soon, though.)

Mike
what do you think of the approach described here
http://bestpracticebank.com/provide-the-value/product-development/user-story-grids/
building upon your model I think

regards
alan, UK

Hello Mike,
We are struggling at our company because we have been calling using the term “stories” to represent engineering work.  We are using a tool now that references Stories and Tasks.  There is a lot of discussion surrounding the definition and use of these two work items.  When should we use a story to describe our work and when should we use a task.

Do you have any opinion on this?
- Bruce

Hi Bruce—
I love it when tools force our vocabulary. (Not really.)

Generally, user stories are used on the product backlog. During sprint or iteration planning user stories are discussed and turned into a set of tasks that make up the sprint (iteration) backlog.

Another distinction is that a task is generally done by one person whereas a user story needs multiple people. That distinction works in almost all cases—“as a patient, I would like to search for a doctor so that I can find the right one for me” is a good user story and needs programming, testing, UI design, database work, etc. “Create the database” would be a good task within that story.  The time when this distinction (one person / multiple) doesn’t work is for a task like “Meet to discuss user feedback on UI design.”  That’s a task: It’s one thing—a meeting. But it involves multiple people.

Mike, there is a serious flaw here…  everyone knows that the Beatles broke up in 1970!

Hi Simon—
Yes, they did. I heard the radio interview in 1973 or 1974 but what I said above was that I think it might have been recorded when they where together (prior to that).

BTW: In 1980 there were lots of rumors swirling that they would reunite. This was because they had almost done so on a Saturday Night Live episode. I remember having a tee shirt that said “Beatles Reunion Tour 1980—I was there. They weren’t.” I loved that.

Great post. One benefit of the ‘As a’ section that I don’t hear very often is that it provides a starting point for planning security - something that too often is saved until last. In many (but not all) cases, there may even be a 1:1 ratio between ‘As a’ user types and security groups, database roles, etc. In the example above, I now know that we’ll probably need to provide roles for ‘estimator’ and ‘moderator’.

Good point, Daniel.

HI Mike, Great article. Plus, your responses to each of the comments have turned it into a great resource on internet. What’s your take on including “Non-functional” requirements in the user story?  Is that advisable?

Thanks, Divik.  For information on non-functional requirements see this blog post: Non-Functional Requirements as User Stories.

Hi Mike, I am fairly new to any agile techniques but I am involved in a large project using scrum where the backlog items read something like ‘Produce an application that processes data from a set of sensors’. This might require reading data from multiple sensor types, validating the data, transforming the data (some of which requires complex algorithms), publishing the data using some pub/sub framework, alert the user of any exceptions. The final app almost always involves some very tight performance requirements which end up needing us to write (and test) multi-threaded code. In general, we are usually only given an interface spec for the inputs and outputs and have to ask lots of questions in order to determine the real required functionality and even then we end up making our best guess at what processing is required. Somehow I get the feeling that this is not really what agile/scrum is all about and that until the PBI is as complete and accurate as can be then we are on a hiding to nothing!! I don’t believe that a user story stating ‘as a user I want a complete sensor processing app to process/transform/validate/publish/notify data’ is the correct level of decomposition. Any thoughts?

Hi Stuart-
Yes, you’re definitely going to want to break those into smaller stories from what I can tell from this distance. Those sound like large stories (which we call “epics”). Those are fine as placeholders way into the future. But when it’s time to work on them, the stories need to be small enough that each can easily be done inside of a singe sprint/iteration.

At the company where I work, we don’t actually “do agile”, more typically we use waterfall, however for a project that’s just started, as lead business/systems analyst here’s the approach I’m leading the project team through.We’ve had a couple of ‘face to face workshops involving business stakeholders and IT:

1. Firstly, we started off with a context diagram (highest level data flow diagram) which shows the system under design (SUD) as a “black box”. On the context diagram we then identified all of the actors (people/roles and systems) that need to interact with the SUD.

2. For each actor we identified high level goals in Verb-Noun format. eg. ‘Make a Payment’, ‘Submit a Claim’ etc

I almost always start off with these two steps for every project as it helps to “set the scene” and assists with high level scope.

Now, normally at this point we would then dive into elaborating Use Cases, and associated functional and non-functional requirements however instead, this time around we are trying out capturing User Stories in the “AS A x I WANT y SO THAT z” format. ie. We are applying that by examining each Actor that was identified and looking at the high level goals (from step 2) as well as asking “what else does this actor want” using the suggested User story template.

We’re using a simple spreadsheet to rapidly capture the User Stories with the “AS A”, “I WANT”, “SO THAT” captured across three columns.

The feedback has been great….the business finds it easy to express requirements in this manner. Also, the value that the “SO THAT” portion has provided for each story
has proved very insightful for the business. We were able to eliminate certain ‘features’ the business thought they wanted but as it turned were not really necessary (by virtue of the business stakeholders not being able to clearly articulate this portion of the User Story.)

Anyway, the main point I wanted to make here is that despite not following an agile methodology, there is still great value is using User Stories with more traditional approaches such as waterfall.

Adam

Hi Adam—
Thanks for the story. You’re absolutely right that user stories are more broadly applicable than pure agile projects.

User story driven development to address non functional requirements like scalability, performance, testability, and maintainability for the system has always been a challenge. It’s very difficult to show value to user in it and they always get prioritized low for first little iteration.  These cross-cutting concerns need to be architected and designed from day 1 into the system otherwise it is leads to design re-work.  Do we have models, case-studies, experience to share on this?

Hi Tribhuwan—
I tend to shy away from statements like “These…need to be architected and designed from day 1…” because even a single counter-examples disproves the “need to be.” I will go so far as to say that many systems benefit from some amount of upfront consideration of these non-functional requirements. You’ll find a lot more on that subject on this blog—for example, see posts on balancing anticipation and adaptation, writing non-functional requirements as user stories, and on design being both intentional and emergent.

There is also, of course, a great deal more in the Succeeding with Agile book.

Hi Mike, great post. I have implemented this approach as a preliminary step before diving into wireframe design for the development of our mobile website. It is a great requirement gathering tool that can be shared across the organization.
Just one question. After we have gathered a list of Stories, should we create Epics based on user types or macro functionality?
Best,
Robert

Hi Robert—
I’m glad you liked the post.

Once you’ve gathered a set of stories, I’m not sure what additional epics you’re thinking of creating. (“Epic” = big user story.) If you’ve got user stories (probably some small and some epics), I would work from that list. I wouldn’t deliberately try to turn smaller stories into epics. I may be missing your true question.

Hello Mike,

Love your work! 

I just want to make sure I am understanding this before I proceed at work.  It has to do with implementing User Stories into Scrum.

I have developed a 3-column template, great idea, and am starting to gather User Stories/Epics.  If I understand this right I can use these stories as actual items in my Product Backlog?  The story board in essence becomes my Product Backlog?

From there we will eventually need to break the Epics into shorter stories but that just adds to the Product Backlog.

We then use the stories and transform them into workable tasks for the Sprint Backlog, right?

Sorry if I am using improper terminology, I am new to this.

Thanks, Michael. I’m glad you like what I’ve done.

I think you’ve summarized it all perfectly. User stories become the items on your product backlog—and yes, the product backlog will have epics and regular stories on it. If you put up a story board that becomes your product backlog. Many teams will also put their sprint backlog on the wall—-organized in rows with columns like “to do”, “in process” and “done.”

I think you’ve got all the terms down perfectly. Good luck!

Actually I find the format: “in order to [get some value] I, as [a certain type of user], would like [some functionality].” much more useful and it focuses on the WHY part which is the part where most organisations I have coached have had problems and benefitted from improvements.

Hi Hass—
Thanks for sharing that. Our experiences have been completely different. Teams I’ve worked with have found that format forced—no one talks like that. So it may work fine among technologists but seems very contrived when working with real users or customers. But, the important thing is to have a variety of ways to try as no one solution will be right for all teams.

Hi Mike,

I have a question or comment regarding the format of user stories, especially the acceptance criteria.  I often feel the context is missing when the typical user story format is used.

I found this resource, http://dannorth.net/whats-in-a-story/ - and it uses the typical user story format, as discussed here, but adds to it a context, which could be described as acceptance critera in more details :)..eg. as a user I want so that…GIVEN, WHEN, THEN..

example from the web site I mention (I only copied one scenario).

“START”
Story: Account Holder withdraws cash

As an Account Holder

I want to withdraw cash from an ATM

So that I can get money when the bank is closed

Scenario 1: Account has sufficient funds

Given the account balance is \$100

And the card is valid

And the machine contains enough money

When the Account Holder requests \$20

Then the ATM should dispense \$20

And the account balance should be \$80

And the card should be returned

“END”

What are your thougths on this? I assume this has been discussed somewhere in details?

thanks,
Hreinn

Hi Hreinn—
I’m not a fan of that format. It doesn’t feel natural. Sure it fits all those tests into one “sentence” but it’s hardly a story. It might as well be an IEEE 830 spec. It seems to miss that the written part of a story is to lead to a conversation. That’s where those details come out. I advocate capturing them as tests or notes on the back of a story card.

Hi Mike!  I’ve enjoyed reading all the comments and especially your response.  I am also a fan of the User Story Template because I think it helps to truly identify your goal.  How do you feel about adding this ‘User Story’ as the scope of a Use Case?  I am working on an Agile project where this format describes the User Goal best but we also need additional information that a Use Case format would supply.

Thanks!

Hi Lianne-
I’m glad you find this blog enjoyable. Some teams will mix user stories and use cases. They’ll write high-level user stories (epics) and use a use case to document the story in more detail, for example. So while I see things like this occasionally, almost all of the companies I’ve seen do this have eventually moved away entirely from their use cases and to just user stories. Similarly in my classes, I hear much, much less discussion about use cases today than, for example, five years ago. Oddly, though, use cases have come up in a ScrumMaster class today and in some client work earlier in the week.

Hello Mike,

We are working on migration project to move many applications/systems from one agency to another. We are physically migrating hardware and software. There are many tasks involved. How can we turn these tasks into user stories with the format you suggested here, when there is no change in the business functionality at all. Few examples of tasks are listed below: (1) Identify Hardware components and software modules to be migrated. (2)Install database server in To-Be environment. (3) Install application software in To-Be environment. (4) Verify integration with connecting systems works in To-Be environment.

For the project you describe and the items you list, I probably wouldn’t use this template. You could convert them to stories if you wanted (“As a developer, I want the database installed in the new environment so that I can program against it”) but I’d probably find little value to that over just “install database in new environment.” Part of the problem is that many of those items are things I’d view as tasks (one-person, one distinct bit of work) rather than user stories (multiple people, multiple steps). Plus, they are obviously technically focused.

I like the advice in the old Al Stewart song, “If it doesn’t come naturally, leave it.” Not everything needs to be forced into any template.

Hi Mike,

Last year, I decided to implement SCRUM in my organization. Since then we are struggling with User Stories and estimations. We are a product development company and almost every month we release a new version of our product. I have a couple of questions:

1. Considering complex products, where Product needs to compliance with complex and lengthy business rules (100 - 200 pages) and processes for e.g: payroll calculation etc, how can we write such things in the form of user stories.

2. Being a Program Manager,I am required to inform my Customers well ahead about the upcoming features in a Release with expected time lines, though in most cases I do not receive dates of a Release from my team unless we do sprint plan of the last sprint in that release.

Appreciate your help.

Hi VQ—

For #1, think of a user story as a pointer to a requirement. Ideally we’d like the story text on a card to “point to” a conversation between some technical team members (programmer, tester and designer, let’s say) and their product owner. Other times, the text on the card points to a document with detail about the thing to be implemented. I have to say, though, I’ve never seen a single story point to 200 pages of business rules. I’m going to guess that’s more like 100 stories. I’d suggest seeing some of the other posts here on stories such as this one on Writing Stories for Back-end Systems and this one on Non-functional Requirements as User Stories. Neither will apply perfectly but they should give you some ideas.

For #2, you need to look into release planning. Sprint planning looks ahead a few weeks. With good release planning in place, a team can look ahead 6-9 months. You can see a great deal more on this in the presentations on this site, in the Agile Estimating and Planning book, and the resource now is my online eLearning course on Agile Estimating and Planning.

Thanks for your input Mike. Your post “User Stories for back-end systems” is really very helpful. We are having almost the similar situation. Could you also please share few references for Release planning.

Thanks again.

Hi VQ—
I’ll stick with the references (on release planning) shared in my previous reply. The best by far is the new eLearning course. But any of the PDFs on planning in the presentations section of the website will be a good start.

I’m wondering how strongly you feel about the terms “goal” and “reason”?  When we describe the story process to clients, we use the terms “action” and “goal” because the middle part of the story template always seems to embody some action that people are wanting or needing to carry out, ie: As a volunteer, I would like to see a calendar of available timeslots, so that I can choose one to sign up for.  The presentation of/interaction with the calendar is the action in that case, and the last part is the goal the user has, or the reason they want to carry out the action. 

Is this just semantics?  Are we talking about the same thing, or is there some deeper meaning to your use of the terms goal and reason?

—Julian

Hi Julian—
Great question. I don’t feel strongly about them at all. I typed them the first time without a lot of thought about “are these the right words?” and have pretty much lived with them since. I suspect your ‘action’ and ‘goal’ are better.