What are agile user stories?

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.

A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.

The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that “customers” don’t have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.

User stories are a few sentences in simple language that outline the desired outcome. They don’t go into detail. Requirements are added later, once agreed upon by the team.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

User stories are also the building blocks of larger agile frameworks like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. These larger structures ensure that the day to day work of the development team (on stores) contributes to the organizational goals built into epics and initiatives.

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.

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.