In Scrum, a User Story is a tool used to provoke, and then summarize, a conversation between the Development Team and their Product Owner, for a better understanding of an item on the Product Backlog. The User Story provides context regarding who a Product Backlog Item is being developed for, and why it is of value.
Are User Stories Part of Scrum?
It’s important to note that a user story isn’t part of Scrum per se, but is a tool that grew up beside Scrum and is often used in tandem. User stories can be helpful but aren’t required as part of the practice of Scrum. When used by Scrum Teams, user stories are placed in the Product Backlog along with anything else that affects the Product.
User Stories Capture Product Feature Requirements in Story Form
User stories replace traditional written requirements. The often-used language of a “Use Case” is stilted and hard to read. A user story acts a reminder of the conversations that created it, to move the focus from What we’re building (what often happens with traditional requirements) to Why and Who. As humans, we’re very good at remembering stories and conversations, but we’re not good at remembering a list of facts. User stories leverage this principle by capturing the main points in the form of a natural conversation.
Thin Vertical Slice
A user story is said to be a “thin vertical slice” – a pithy statement that is hard to digest. “Thin” is just a funny way of saying they’re small. Small enough that a couple of team members could finish one in a few days of work. “Vertical Slice” – imagine software to be composed of layers, for example: User Interface, Business Logic, and Backend systems. So an item that goes through all the layers is a vertical slice. A horizontal slice would focus only on a single layer or components.
How to Format a User Story
Everyone who has seen a user story before can rhyme this format off:
“As a <User/Role>, I want <to do something> so that <value>”
This is so popular that many people think this is a User Story itself. (It’s not.) The original user stories (going back to 1996/7) had no predetermined format. The above format is just one of several that is popular today. Here are two more:
“As a <role> I want <business value> by <method/requirement>”
“In order to <achieve some value> as a <type of user> I want <some functionality>”
If whatever user story format you’re using isn’t helping the Scrum team have a good conversation around what the end user wants and why they want it, then abandon it and create a new format. The exact user story format isn’t important – the goal is simply to be clear on who wants what and why. Present it in the form of natural language, rather than technical jargon, to make it easier to understand and remember. It also makes it more human-oriented, which helps a ton with motivation.
Typical components of user stories, often referred to as the three C’s:
- Conversations: discussion of the details. Results in creating the acceptance criteria.
- Confirmations: Acceptance criteria that, in software, can be turned into automated acceptance tests.
- Card: A physical token (with a story title/description) traditionally written on a small paper card or sticky note to aid in planning. Acts as a reminder to have conversations.
Need, But Not a Solution
User Stories explain the need behind a product or feature, but not the solution. Traditional requirements often didn’t state the need, and instead they worked through the fine-grained details of what to implement without showing the team why it mattered. It is difficult to do a good job building a feature when it’s not clear why it’s needed. Worse, it’s demotivating. We need to see that our work has meaning and purpose. A user story is intended to state the business need in addition to what the story will accomplish.
Are Stakeholders involved in User Stories?
Some Scrum teams invite interested stakeholders (e.g. Marketing or Sales Manager, a real live end user) to the Sprint Review when they’re working on features that are especially important to the stakeholders. In these cases, the User Story facilitates the conversation between the people who want the feature (the Stakeholders) and the people building it (Scrum Team), and the team and Product Owner get to hear firsthand about the underlying need or rationale behind the product request. Once the Developers understand the intention behind the feature, and what the end user wants to achieve, they can get to work and figure out best possible solutions for how to build it.
A User Story is Different From Definition of Done or Acceptance Criteria
“Where do the details go?” is a question I often hear in Product Owner workshops. The original user stories had the text of the story on the front and the detailed acceptance criteria on the back. Specific details about what a story allows and disallows become the acceptance criteria, that are effectively the children of the user story.
Confusion over what is a user story vs. definition of done vs. acceptance criteria is one of the most common problems in Scrum, and we cover it in detail here. But, in a nutshell, Definition of “Done” is the global quality checklist for all user stories. Acceptance criteria are the specific details needed to complete a user story. A user story is a placeholder for a conversation about meeting a User need.
Goals of a User Story
- focus on the problem that needs solved, not the solution to the problem
- start a conversation about what problem to solve, why it needs solving, and who needs it
- demonstrate a need as concisely and simply as possible
- be a small, vertical slice of functionality
Life Cycle of a User Story
Story Slicing, How Small is Enough?
More Notes on Story Splitting
Vision to User Stories – What is the Best Flow?
Scrum By Example – The Team Collaborate on Acceptance Criteria
Scrum by Example – How to Deal with Bad User Stories as a ScrumMaster
- Alternative formats for User Stories
- Another Alternative User Story Format
- Conversational Stories
- Examples of User Stories
- How to Break a User Story into Tasks
- Introduction to User Stories Presentation
- Not Everything Needs to Be a User Story: Using FDD Features
- Sprint Tasking Tips: Sticky Note Strategies
- Sprint Tasking Tips: Team tasking strategies
- User Story: a Placeholder for a Conversation
- User Stories and FDD
USER STORIES BOOKS
(Updated: November 2023)
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.« Back to Glossary Index