You are not a member of this wiki.
User Story Basics - What is a User Story?
Details of Coaching and Consulting services
For Training, Coaching, and Consulting engagements, please
for details on how I can help your organization.
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
. User Stories are but one technique 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 & #8 of my article on
User Story Traps
What is a User Story?
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:
written description or short title
of the story used as a token for planning and as a reminder to have conversations(Card)
about the story that serve to flesh out the details of the story(Conversations)
that convey and document details and that can be used to determine when a story is complete(Confirmations)
Ron Jeffries, the co-inventor of the User Stories practice, refers to these three components as
Card, Conversations, and Confirmations
, otherwise known as "The Three C's."
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
, 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
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. Sometimes the Product Owner will do the first draft of Acceptance tests. 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 backlog grooming. 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?
User Stories article on Agile Atlas
(New! March 2013 - I co-wrote this one -- great article if I do say so myself!)
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 why there really is no such thing as a "Technical Story", see
Technical Stories: We Don't Need 'em
To see how to make sure your stories are "ready" for implementation, check out Roman Pichler's article,
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
To see more information on grooming user stories, see:
What does Product Backlog Grooming Look Like?
Tips for Effective Backlog Grooming
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
I wrote a skit for a
I did at MileHighAgile 2011 that demonstrates a team doing Product Backlog Grooming for a User Story. In the skit, backlog grooming is covered pretty well, with the one exception that estimation was not covered in the skit. You can read the script of the skit here:
For good advice on how to split User Stories, see Richard Lawrence's
Story Splitting Flow Chart
For a good article explaining how to split User Stories vertically, see:
Splitting Stories into Small Vertical Slices
For a good article on why to split User Stories, see Mark Levison's
Story Splitting, How Small is Enough
help on how to format text
Turn off "Getting Started"