Definition: A user story is a small, self-contained unit of development work designed to accomplish a specific goal within a product. A user story is usually written from the user’s perspective and follows the format: “As [a user persona], I want [to perform this action] so that [I can accomplish this goal].”
What is a user story?
In agile software development, a user story is a brief, plain-language explanation of a feature or functionality written from a user’s point of view. Many agile experts also describe a stories as the smallest unit of product development work that can lead to a complete element of user functionality.
Product teams choose to break development work into user stories instead of product features or product requirements for several reasons.
- Are easy for anyone to understand
- Represent bite-sized deliverables that can fit in sprints, whereas not all full features can.
- Help the team focus on real people, rather than abstract features
- Build momentum by giving development teams a feeling of progress
What does a user story look like?
Most product teams use a similar user story template, typically just a sentence or two written according to the following formula:
As a [description of user], I want [functionality] so that [benefit].
User story examples
In practice, user stories might look like these:
- As a database administrator, I want to automatically merge datasets from different sources so that I can more easily create reports for my internal customers.
- As a brand manager, I want to get alerts whenever a reseller advertises our products below agreed-upon prices so that I can quickly take action to protect our brand.
- As the leader of a remote team, I want our team-messaging app to include file sharing and annotation so that my team can collaborate in real-time and keep an archive of their work in a single place.
As you can see from the third example above, the persona in your user story does not need to be limited to a person’s job title. A “leader of a remote team” could be a department manager, company vice president, the CEO of a small startup, or any number of other roles in an organization.
But for the purpose of explaining this story — allowing users to upload a file to your team-messaging app and then make native annotations to that file — it makes sense to describe the user for that feature as someone who oversees a team of colleagues working in different locations. The various users described in the stories your team writes might in some cases be the same person needing different functionality for different tasks.
Who should write user stories?
In many agile organizations, the product owner takes primary responsibility for writing user stories and organizing them on the product backlog. In reality, though, this is a shared responsibility among the entire cross-functional product team.
In fact, one of the reasons they are written in plain language — free of any development jargon or technical detail — is that this allows anyone on either the business or the technical side of the team to contribute a user story for consideration. That team member (product manager, UX designer, etc.) only needs to have an understanding of the specific user-persona problem they are hoping to solve. They do not need to know how the development team will actually code that solution.
User story vs. use case: what’s the difference?
Like user stories, a use case describes how a user might interact with a product to solve a specific problem. But the two are not interchangeable; they are different tools used in product development.
Ivar Jacobson, who is credited with developing the use-case concept, explains that use cases document both a user’s goal and the functional requirements of the system. In other words, use cases are designed to capture much more detail than a user story about the process a user goes through to achieve the desired outcome from interacting with a product.
Whereas a user story is written as a very brief statement describing only the user’s end goal, a use case often describes several additional steps, including:
- The preconditions required before the use case can begin
- The main flow of events (also called the basic flow) describing a user’s path, step by step, to completing an action with the product
- Alternate and exception flows, meaning variant paths a user might take with the product to complete the same or similar goal
- Possibly a visual diagram depicting the entire workflow
How do you write a user story?
Here’s a simple, six-step process for crafting user stories:
Step 1: Decide what “done” will look like.
In most cases, the user story describes an end-state: when the user is able to complete the task or achieve the goal described. You need to have this end-state in mind when you write yours, so the rest of your team knows when they can mark the development work done. (Learn more about the definition of done.)
Step 2: Document tasks and subtasks.
Although your actual user story will include only the standard statement we described above — “As a [persona], I want [feature] so that [reason]” — you will also need to document the details required to complete the development work described in the story. That means outlining tasks and subtasks and assigning them to the right people.
Step 3: Determine your user personas.
Who is served in this story? Which type of user or customer? You need to document this upfront. If you have several different users in mind, you might want to break this into more than one user story. This way your team can stay laser-focused on helping a specific persona achieve a specific objective for each story.
Step 4: Create stories as ordered steps.
The concept of user story mapping suggests that you can think of your entire product as a series of tasks or jobs the product helps your users complete. With that in mind, if you’re trying to structure work on a larger process or a more comprehensive set of product functionality, write each self-contained step as a story.
Step 5: Seek user feedback.
To improve your chances of allocating resources to development work that will resonate with your market, talk to users and customers about their priorities and learn what more they want from your products. Only after gathering and analyzing this feedback should you begin crafting user stories.
Step 6: Draft stories that can be completed in one sprint.
User stories that take longer than a single sprint (typically two weeks) should be broken into smaller stories. This way, your team gets a sense of completion in each sprint, because they’re able to complete some new functionality each time. It also allows your team to push out new functionality to the market more frequently.
Product teams, why wouldn’t you write with your users in mind?
Aside from the fact that they’re designed to fit on index cards and can be easily understood by anyone, one of the biggest advantages of user stories is that they can help you from getting lost in the technical details of your product’s backend or from becoming enamored with a UX you believe is elegant but that isn’t actually structured in a way your users prefer to work.
User stories help your team accomplish all of this — and build better products — by forcing you to make one simple change to your approach to development planning. Rather than writing up your plans from the product’s point of view (which features to build), user stories force you to draft each proposed idea for new functionality from the point of view of the actual people who will be using that functionality.