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.
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.
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
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.
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.
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.