One of the biggest challenges of software development is the nearly impossible task of gathering clear requirements and expecting those requirements to remain unchanged while the code is developed. In the waterfall approach to software development—despite efforts to define, document, and approve every possible contingency before development begins—the delivered product is rarely what the customer wants.
The agile alternative? User story creation. One of the biggest advantages of using an agile approach to software development is that the requirements aren't set in stone but instead are expected to change, with constant feedback from stakeholders and the business. Agile methodologies such as Scrum and Extreme Programming (XP) replace traditional, lengthy requirements documents with a prioritized product backlog made up of concise user stories, the details of which emerge closer to when the story is ready to be implemented. Here are tools and tips to ensure everyone on your team is an expert in user story creation.
The history of user stories
XP first introduced the concept of user stories in 1998, comparing them to use cases. In the 1992 book, Object Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson introduced use cases as a way to document requirements by defining interactions between a role and a system to achieve a goal using the Unified Modeling Language (UML). This approach was popular in object-oriented development and is still used as a key process in software development frameworks, such as the Unified Process (UP), the IBM Rational Unified Process (RUP), and the Oracle Unified Method (OUM). Using use cases, rather than user stories, allows for iterative and incremental development and is considered an agile approach to requirements definition.
[ Also see: To agility and beyond: The history—and legacy—of agile development ]
With the introduction of user stories and the popularity of XP and scrum, a product backlog made up of user stories became the more commonly known approach to agile requirements definition, with many thinking that user stories are the only acceptable agile approach. However, Alistair Cockburn, one of the Agile Manifesto's signatories, prefers use cases to user stories. Though there are plenty of strong opinions about the meaning of "agile," both use cases and user stories are compatible with agile. Some say user stories eventually become similar to use cases once the team agrees upon the details of the implementation. In the early stages, the user story is simply a short sentence but isn't complete until the details and acceptance criteria are defined.
Creating user stories
There are varying opinions on the definition of a user story and the best way to go about creating one. Some guidelines for a good user story include:
- It should be written by someone who represents the business users (usually the product owner)
- It should initially include brief descriptions of the "who, what, and why" but not the "how"
- It should produce a vertical slice of working code
- It should be small enough that it can be coded and tested in one iteration (usually a one- to four-week period)
Various templates, techniques, and acronyms are used to help product managers write user stories. Three of the most common techniques are the role-feature-reason template, the Three Cs (card, conversation, confirmation), and INVEST (independent, negotiable, valuable, estimable, small, testable).
As Mike Cohn of Mountain Goat Software explains, the role-feature-reason template, or RGB (role, goal, benefit), looks something like this:
"As a [type of user] I want [some feature] so that [some reason]"
Although there are variations, this short sentence helps keep the focus on the who, what, and why. This prevents the product owner from giving the development team too much information about how they should implement a solution. Instead, by focusing on the who, what, and why, the development team is empowered to find the best technical solution.
The Three Cs is a formula developed by Ron Jeffries to help reach agreement between the business and the technical team on the meaning of the user story. Though the user stories are initially brief (short enough to fit on an index "card"), before the development team implements the code, they have a "conversation" to clarify details. It's during this conversation that the team often discusses acceptance criteria and the definition of done. The development team needs to have a clear understanding of the story and what should happen in various situations, including error conditions. When the team is clear on this and the business and technical team are in agreement about what's expected of the completed story, there's "confirmation."
This discussion results in refinement of the story with additional details, which may not be in the same format as a use case but should give the development team the details they need to design, develop, and test the code.
Story mapping and personas
Though we've covered the basics of creating a user story, the big picture must be understood before user story creation can begin.
Typically, the product is broken into groupings that go by names such as themes, epics, or features. These then get broken down into the smaller user stories that the development team often breaks down even further into tasks.
In the early stages of product development, the team identifies the users of the system and what features they'll need. Then they determine the minimum viable product (MVP)—what is the minimum that can be released that will add value and generate revenue?
Users are broken out into personas to represent certain types of users that may have different needs. By creating personas, the team is able to conceive different user segments and think more from their perspective, and stock photos and fictional names help the team better understand the functions each role would need.
Story maps provide a way to organize functional activities by user activity. Although there are various methods for how to go about this exercise, one way to structure a story map is to list features horizontally on a grid and break those into stories listed in columns below each feature. Personas, or user roles, and the highest-priority workflows are then mapped out. This helps identify the high-priority stories.
Impact mapping
Another strategic planning technique used to help understand the big picture is called impact mapping, popularized by Gojko Adzic, author of Fifty Quick Ideas to Improve Your User Stories and Impact Mapping: Making a big impact with software products and projects. Impact mapping is a mind map that starts with the goal, which should address the question of value and why you're building the product. The next level lists the "actors," or the people who will help accomplish the goal. Next, the map lists the behaviors, or "impacts," the actors will perform in order to help accomplish the goal. The final level of the map is the "deliverables" the team can implement, which will enable and support the actors to create the desired impacts. It's from these deliverables that software features and stories can be derived.
In Impact Mapping, Adzic shares an impact map for an online gaming application, with the goal being to gain one million players. The actors include game players, internal employees, and advertisers. The players can invite friends, recommend the game, or create posts. Finally, a deliverable that the team may implement is an automated invite feature. Translating this into a story using the role-feature-reason template would result in, "As a player, I want an automated invite feature, so that I can invite friends."
Mapping user stories out in this manner allows traceability into the thought process of how the stories ultimately create value and are used to achieve the end goal. The idea isn't to implement everything but to find the shortest path through the map to achieve the goal.
The biggest challenges
Though newbies may think that creating user stories provides an easier approach to requirements gathering than the traditional waterfall approach, many major challenges still exist, even in mature agile organizations. Gathering the requirements that will add the most value to the user and converting those into stories a development team can deliver is no simple feat.
Author of User Stories Applied For Agile Software Development and founder of Mountain Goat Software, Mike Cohn is one of the most well-known experts on agile user stories. Whether you're estimating stories using Mountain Goat Planning Poker cards or you're googling advice on how to best split a story, you're going to come across Mike Cohn's work. His humble demeanor belies his knowledge, and his experience in agile circles makes him a favorite mentor for those seeking advice.
Cohn's take on the biggest challenges with user stories? He notes:
- Splitting stories to fit in sprints/iterations
- Keeping track of a big picture while working with small stories—not losing sight of the vision
Splitting stories
One of the most common problems agile teams run into is that their stories are too big and can't be completed in an iteration. Teams can sometimes address this by splitting a bigger story into smaller stories.
One way to split stories is by using acceptance criteria. In other words, if there are multiple acceptance criteria in one story, consider splitting the story so each story has only a single acceptance criterion.
Another reason a user story might need to be split is that there isn't enough information for the team to feel comfortable enough to accurately estimate it. As the story is being discussed, the product owner may not know the answers to some of the questions the team asks. The team may not know enough about the technology or design to feel comfortable with an estimate. In such cases, it might be better to create what's referred to as a "spike," or a story that is meant to gather information, rather than produce shippable code.
In the free sample chapter of User Stories Applied For Agile Software Development, Cohn describes the usage of spikes and advises to put the spike in a different iteration:
When possible, it works well to put the investigative story in one iteration and the other stories in one or more subsequent iterations. Normally, only the investigative story can be estimated. Including the other, non-estimatable stories in the same iteration with the investigative story means there will be a higher than normal level of uncertainty about how much can be accomplished in that iteration.
Agile coach Richard Lawrence has some excellent materials about splitting stories as well. Lawrence identifies nine patterns for splitting stories depending on the type of functional complexity. He has a cheat sheet of example stories for each pattern and a poster that helps explain the methodology.
Keeping track of the big picture
A keynote speaker at the Agile 2015 conference in Washington D.C., Luke Hohnmann is the founder and CEO of Conteneo Inc., formerly The Innovation Games Company, which offers games aimed at helping product owners create and prioritize product backlogs. Hohmann is known for his ability to use games to help agile teams collaborate.
Hohmann's overall advice addresses the second challenge Cohn mentioned: keeping track of the big picture. In order to do this, it's important for the product owner to do the research necessary to understand customers' needs. This is Hohmann:
I think there is a distinction between the market research that creates the foundation for generating user stories and the user stories themselves. In other words, product managers don't expect to walk up to customers and say "What user stories do you want us to build?" and then have their customers magically enumerate a bunch of user stories.
Instead, product managers engage in various forms of market research to identify unmet market needs, unmet customer needs, [and] desired enhancements, and blend this research with trends, feedback from the technical team, competitive analysis, and so forth. Armed with these data the challenge of writing effective user stories is much easier.
Hohmann feels that the biggest challenge or impediment with regard to user stories is that some product owners feel they need to write everything as a user story. He says:
I recently worked with a large Silicon Valley company who was really struggling with agile. When I finally got a look at their backlog the root cause was easy to diagnose: EVERYTHING on their backlog was written as a user story. When I asked why, the answer I got was "Because the agile consultants we hired to help us told us that everything had to be written as a user story."
Ouch. While perhaps well-intentioned, the admonition to write everything as a user story is overly simplistic, myopic advice. We don't write every PBI (product backlog item) as a user story. No one should.
Turn to the community for deeper learning
Detailed solutions on how solve the toughest problems relating to requirements and user stories is unique to each story. However, one common trait of most agile practitioners is that they're eager to help others and share what they know.
Cohn's userStories website allows those who work with product backlogs and user stories to share products, resources, and knowledge. The products page includes an impressive list of tools, many available for free, with opportunities for user reviews and input. Cohn notes on the site that he hopes to expand the site so the product backlogs can be shared.
All the experts mentioned in this article have a plethora of material available online, as well as courses, books, presentations, slideshows, and blogs that help answer tough questions. There are many others in the agile community who are always willing to help.
There's never going to be a one-size-fits-all answer on how to write perfect user stories. However, over time, with a healthy mix of experience, advice from the experts, and experimentation with suggested tools and techniques, you can continually improve.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
