User stories are the basic unit of agile development. They are simple descriptions of a feature from the user’s perspective. I’ve relied on these for the past 15+ years as a software developer and manager. You can use them to define requirements, grasp what the customer is trying to do, and drive the development process. So, how do you write great user stories?
User Story Structure and Components
A user story is structured as “As a [user], I want [goal] so that [benefit].” It’s a simple, one-liner description of who the user is, what they’re trying to do, and why it matters to them.
Ron Jeffries, one of the original creators of Extreme Programming, introduced the concept of the three C’s in user stories:
- Card: The written description of the story
- Conversation: Talking through the details
- Confirmation: Acceptance criteria for when the story is done
When writing user stories, make them as concise and clear as possible. Don’t worry about making them overly technical or detailed. Use simple language non-technical team members can understand.
Here are a few tips to ensure you write great user stories:
- Identify the user role.
- Clearly define the goal or action.
- Explain the value or benefit.
- Keep it simple and short.
- Write in active voice.
- Avoid any technical descriptions.
You need to think about what the user is trying to accomplish. Using this framework will help you ensure you only build features users actually care about.
User Story Examples for Different Industries
User stories are very flexible and can be used in virtually any industry. Here are some examples of user stories to help you better understand how they’re used in different industries.
E-commerce user story examples:
- As a shopper, I want to add items to a wishlist so I can easily find them again later.
- As a customer, I want to filter products by price range so I can find items within my budget.
Social media platform user story examples:
- As a user, I want to block unwanted followers so that I can maintain my privacy.
- As a content creator, I want to schedule posts in advance so I can manage my time effectively.
Banking application user story examples:
- As an account holder, I want to set up automatic bill payments so I don’t miss due dates.
- As a new customer, I want to open an account online so I can avoid visiting a branch.
Educational software user story examples:
- As a student, I want to track my assignment deadlines so I can manage my workload.
- As a teacher, I want to create custom quizzes so I can assess my students’ understanding.
Healthcare management system user story examples:
- As a patient, I want to book appointments online so I don’t have to wait on hold.
- As a doctor, I want to access patient history quickly so I can make informed decisions.
These examples illustrate the broad range of specific needs user stories capture in different industries. Each user story focuses on the user’s goal and what they’ll get out of a particular feature.
Best Practices for Writing Effective User Stories
Writing good user stories is a key factor in achieving successful project results. Here are some of the best practices I’ve discovered for writing effective user stories.
Keep stories simple and to a single piece of functionality. This approach makes it easier to estimate, implement, and test the functionality if the story is a single piece of functionality.
Write stories in active voice and use very specific language. This ensures team members know exactly what to do. Avoid using high-level, vague language or technical jargon that non-technical people won’t understand.
Make sure the story is testable. In other words, you should be able to verify that the functionality works as expected. Typically, this means defining clear acceptance criteria.
- Include acceptance criteria within each story. These are the criteria that define the functionality is “done.” For example:
- Specific conditions that should be met
- Critical user interactions
- Any performance thresholds
- Error cases to account for
Order stories by business value. This ensures you’re always building the highest impact item at any given time.
Have multiple people come up with stories. More people will always generate better results than a smaller group or a single person. Their collective input will ensure you create a more thorough story.
User Story Estimation and Sizing
Story points are a popular way to estimate complexity. Unlike time-based estimates, story points are a relative measure, accounting for complexity, uncertainty, and effort.
Planning Poker is a common estimation technique, where team members individually assign point values to stories and then discuss to reach a consensus. Alternatively, using t-shirt sizes (S, M, L, XL) is an easier method for quick high-level estimates.
When estimating stories, consider the following:
- Complexity of the task
- Amount of work required
- Any risks or uncertainties
- Potential dependencies on other stories
To estimate stories, you should split large stories, often referred to as epics, into smaller, estimable pieces, which is known as splitting stories. Consistently estimating stories helps you size them and ensure they are completed within a single sprint.
It’s also important to ensure the team consistently assigns the same sizes to stories, as this allows for more accurate velocity calculations and sprint planning. To solve this, teams can hold a regular calibration session.
User Stories in Agile Frameworks
• User stories are a core element of various agile frameworks. In Scrum, the product backlog is made up of user stories. In sprint planning, the team selects which user stories it will work on in the upcoming sprint.
• On kanban boards, user stories are often used as the work items. They move from “To Do” to “In Progress” to “Done,” representing the work item’s progress on the board.
• User stories are one of the primary discussion points in sprint planning and backlog refinement meetings. The team discusses, reviews, and estimates which user stories it will work on next.
• User stories fit within a hierarchy in agile frameworks. At the top level, you have themes or initiatives. These get broken down into epics, which then break down further into individual user stories.
• Progress tracking in agile most often involves the completion of user stories, which is a direct representation of value delivered to the end user.
User Story Workshop and Collaboration
The most common place to hold a story writing workshop is at the beginning of an agile project. This is a group activity where all of the team members and stakeholders get together to write user stories.
When organizing a workshop, follow these steps:
- Define the objectives of the workshop.
- Decide who should participate.
- Gather materials (sticky notes, whiteboards, etc.).
- Choose an ice breaker to kickoff the workshop.
There are several different team story writing techniques:
- User role mapping
- Story mapping
- The five whys
- Brainstorming sessions
- Affinity diagramming
It’s important to include stakeholders in the story writing process, as they can offer key insights about user needs and business priorities. Additionally, involving stakeholders in this process ensures that they feel ownership over the user stories created.
Using personas to create user stories is an effective strategy. Personas are fictional characters that represent different user types. By creating personas, a team can more effectively empathize with users and write stories that directly meet the needs of each particular persona.
If the workshop is remote, use a digital whiteboard tool like Miro or Trello to virtually map the stories. These tools allow everyone to collaborate in real time on a digital whiteboard or Kanban board.
Common Pitfalls and How to Avoid Them
The most common mistake I see is writing overly technical user stories. It’s easy to get caught up in the excitement of a solution, but as a general rule, most user stories are too technical. Instead, focus user stories on user needs, not how you’ll solve them. Keep your language simple and user-focused.
The other common problem is failing to include the benefit (or the “why”) in a user story. The danger here is that the feature you build won’t actually deliver any real value to the user. Always make sure to capture the reason the user is asking for the feature.
The final pitfall is stories that are either too large or too vague. If a user story is vague, it’s impossible to estimate or complete it. And if it’s too large, it’s likely too much work for a single sprint. If you can’t complete a story in a single sprint, then it’s probably too big.
The other problem I see is failing to involve everyone in the story-writing process. Someone doesn’t invite the entire team, and inevitably, a few perspectives are missed. Then, the story is either incomplete or isn’t what the user actually wanted. Make sure every team member participates.
Most people don’t capture non-functional requirements in a user story. If it’s a performance, security, or usability requirement, incorporate it into the story.
Here’s how to overcome these challenges:
- Use a story template to ensure you capture everything.
- Review and refine stories as a team on a regular basis.
- Practice writing stories together to build your skills.
- Use acceptance criteria to clarify exactly what you need to build.
- Ask users and stakeholders for feedback.
By avoiding these pitfalls you’ll create more effective user stories that truly capture user needs and drive successful project outcomes.
Closing Remarks
User stories are the foundation of agile development. They communicate user requirements, direct development and promote teamwork. When teams think about the user, goal and benefit, they build useful, specific solutions. And that’s why writing effective user stories is the key to a successful sprint or project. With some practice, you’ll become adept at this critical agile skill and build better products that actually fulfill user needs. So keep iterating on your process, and you’ll see more successful projects.
