What is a User Story? I’m glad you asked!
First of all, it’s important to say that User Stories are not a part of Scrum as defined in the required practices in the Scrum Guide. User Stories are but one way to represent Product Backlog Items in Scrum, and while it is the most popular method used, it is not the only method. Still, though, I would like to remind you that the User Stories practice is totally independent of Scrum, and thus it is not defined by Scrum. As such, everything else in this post is about the User Story practice and not Scrum itself.
Beware the common misconception!
There is a common misconception in the industry that a User Story is a sentence like:
- As a <user> I want <some functionality> so that <some benefit is realized>.
THIS IS NOT A USER STORY!!! This is the biggest User Story trap in existence! See Trap#1 and #8 of my article on User Story Traps.
What is a User Story?
<Definition>
A user story describes functionality of a system that will be valuable to a Non Development Team(NDT) stakeholder of a system or software. User stories are composed of three aspects:
- a written description or short title of the story used as a token for planning and as a reminder to have conversations
- conversations about the story that serve to flesh out the details of the story
- acceptance tests that convey and document details and that can be used to determine when a story is complete
</Definition>
What do they mean by Acceptance Tests?
Typically, in the context of a User Story definition, we mean tests that are represented by conversations, textual descriptions, tables, diagrams, automated tests, and so forth. When these Acceptance Tests are applied to the completed, implemented User Story, all of the tests should pass, and will thus prove that the story has been implemented correctly. If some functionality was not covered in a User Story acceptance test, then it wasn’t a requirement for that particular User Story.
Technically, in the context of a User Story definition, an acceptance test need not be automated or implemented. At the minimum, it should be described conceptually. The test should then be executed in order to prove the story and get acceptance, whether that be a manual or automated process. If your conceptual acceptance tests are described by one or more automated tests, then that is generally a much better practice, but not absolutely required.
Acceptance Tests should be automatable about 90+% of the time, though again, it is not required that they be automated. Having said all of that, when teams strive for development speed and quality, very few get far along that road without automating a large portion of their acceptance tests.
Acceptance Tests, in the context of User Stories, are also sometimes called Story Tests, Acceptance Criteria, Conditions of Satisfaction, and Test Confirmations.
Ron Jeffries, one of the co-inventors of User Stories and Extreme Programming (where the User Story practice comes from), has a good article that also describes User Stories in a basic way.
When do these Conversations and Acceptance Tests get created?
Typically, this happens in weekly Product Backlog grooming(also known as a Story Writing Workshop, Story Grooming, etc) sessions, but can also happen informally. The most effective backlog grooming includes some stakeholder/user representatives, the entire development team, and a Product Owner (Scrum) or Customer(XP). These sessions happen weekly and usually last 1-2 hours each. The goal of the sessions is to get stories that are “ready”, meaning the team has a shared understanding of the Acceptance Tests, and has the vast majority of the information they need to implement(code) the feature. See What does Product Backlog Grooming Look Like? for more on that topic. Keep in mind that sometimes a single User Story will be discussed in 2-3 grooming sessions before it is “ready”, especially if there are open questions or complex logic involved.
Frequently Asked Questions
Should I use a User Story to represent bugs/defects in a system?
The short answer is “it depends.” If it is a legacy or deferred bug, then yes, and it should end up on the Product Backlog(story points assigned). If it is a bug that was introduced since Scrum/Agile was put in place, then no, and it should end up on the Sprint Backlog(no story points assigned). See One way to handle Bugs and Production Support in Scrum for the longer answer.
Where do I get more info?
- A User Story Checklist
- User Story Basics – The Longer Story
- To see what User Story Traps cause a lot of pain on teams, see User Story Traps
- To see how to make sure your stories are “ready” for implementation, check out The Definition of Ready
- To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
- To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
- Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
- The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.
Filed under: Product Backlog, Product Backlog Grooming, Product Owner Tips, ScrumMaster Tips, Story Points, User Stories |
The Scrum Crazy Blog 
[…] about crafting good user stories in his Scrum Crazy blog. In a blog post he starts by discussing what a user story is and go right to the point is saying that a user story is NOT a “As a I want so that”. […]
Charles as you point out that many people are getting confused about what a User Story is i see that its a very widespread problem, im currently reading Agile Project Management For Dummies and even within the book they have stated it wrong.
Charles ive noticed though after skimming over a few blog posts here and there that many people are doing it the way that you suggest is wrong, They are even giving explanations of why they prefer doing it that way, others mixing it up even more and referring to them as a template that they use for their user stories.
What is your opinion on this? Is it just that people have expanded on the initial way of writing a user story or do you truely feel that it should only be done in the way as suggested above, i mean if they are still holding a conversation for each story and acceptance tests are in place too….
John,
Thanks for your comments.
My opinion on the US template is that, in general, it is bad for the industry because it leads people back to primarily textual requirements, which I consider a waterfall habit that is far inferior from the true User Stories practice.
In the rare case that a team uses the template only as a starting point for the conversation and confirmations, I’m ok with it. However, that is very rare in my experiences.
I should also mention that, to the teams that do the conversations and confirmations well, that the template has very little value in their practice as much of the info that would exist in the template would then be conveyed via conversations and confirmations. Hence, they would no longer really need the template.
Charles thanks for confirming what i was thinking regarding this, ive recently commented about this on another blog, that other person is adamant that they are doing it correctly, but im more comfortable with your suggestion.The fact that you point out that it leads to people falling back on textual requirements, after seeing people writing about this template that they are using and others that are similar and having weeks ago read the book by Mike Cohn it resulted in quite a bit if confusion for myself.
Im glad that i came across this particular article because it reminded me of what i had read from the book, i have yet to use agile so fortunately haven’t picked up any bad habits but i might have come close to a few.
It seems then that many are missing the point of user stories or they do understand what to do but are then following the template that some are using and forgetting about or trying to skip the conversation part of the process.
Seems a pity that some might be missing out on from what i understand of agile so far to be one of the major benefits of it, that being to have conversations, plenty of communication.
John,
> Seems a pity that some might be missing out on from what
> i understand of agile so far to be one of the major benefits
> of it, that being to have conversations, plenty of
> communication.
In your comment that I have quoted above, you have pretty succinctly described the majority of the software development market, IMO, at least in the US. My guess is that the rest of the world is not that different, but I don’t have enough non-US data to back that up. It is a pity, and I’m not exactly sure what to do in order to set it right.
It’s very difficult to describe collaboration and communication with the written word. Many of us who speak on the subject at conferences and organizations and such do our best to include interactive exercises to help convey to attendees what “Individuals and Interactions” really means, and how much fun Agile can really be.
On this same topic, this blog article might also give you some more info on how I view the Agile industry at this point:
Those of us who do “get it” need to continue spreading the word in as positive a way as we can muster. The march continues!
I do hope that more people pick up on what you are saying, im glad that i found this article because there wasn’t that much time between myself finishing reading the book by Mike Cohn and reading the incorrect template way and it was making me forget what i had first read about what a user story was, it shows how easy it is to go from understanding the right way to do it to then actually getting confused and thinking that the template(s) was the way, literally from reading about it a few times on various different blogs.
Thanks for the link Charles, going to read that article straight after this reply.
I really appreciate having a better understanding of what is truely a user story now and of course the reason that they are written in the first place.
[…] soit une spécification fonctionnelle détaillée en bonne et due forme, ou bien une liste d’US (https://scrumcrazy.wordpress.com/2012/05/03/user-story-basics-what-is-a-user-story/) rédigées de manière concise et claire. En tant que développeur, on pense tout d’abord à la […]