User stories are short and simple descriptions of capabilities. They are written from the perspective of a user or customer of the system.
But they’re not.
A key component of agile software development is putting people first, and user-stories put actual end users at the center of the conversation. Stories use non-technical language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building what they’re building and what value it creates.
User stories are one of the core components of an agile program. They help provide a user-focused framework for daily work — which drives collaboration, creativity, and a better product overall.
They typically follow a simple format:
“As a [persona],
I want to [do something]
so that I can [realize a reward]”
This format is designed to help the story writer be descriptive and to drive better discussions about implementation with the rest of their team. Done right, the format helps prompt the following important questions:
If answering those questions seems like a lot of work, I’ll mention here that taking stock of new product failure rates, IT project failures, and the portion of features that actually are substantially used, something on the order of most or at least ‘a lot’ of software ends up lightly used or quickly scrapped. Skillful use of stories will improve your outcomes, your economics, and, most importantly, your team’s sense that the work they’re doing matters to the user.
If you’re writing a story, your job is the fill in the (red) blanks. The persona is a vivid, humanized, yet operational description of your user. The ‘[do something]’ is a goal you assume the user has. The ‘[realize a reward]’ clause is a testable statement of how you’ll know if the user realized that goal. The [realize a reward] clause is the most neglected by most story writers and yet it’s the most important. The single best litmus test for whether you have a good story is whether you could put a simple prototype in front of a user, ask them to act on the goal you’re assuming, and see if they can achieve it.
Let’s look at a specific example to see how that would work in practice. “BestHR” is a fictional company. They’re (fictionally) building an app that allows an HR manager to screen job candidates for a specific, technical skills sets relative to a job description. We might describe the goal of building a quiz to screen for a new open job description with this story:
“As an HR manager, I want to match an open position’s required skills with quiz topics so I can create a quiz relevant for candidate screening.”
With this story, a designer or developer (or someone acting in that role) could put a sample job description in front of an HR manager, give them the goal of picking quiz topics for it, and see if they’re able to realize that goal with the team’s current prototype or working software.
Do user stories replace a requirements document?
Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.
While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.
It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.