User stories: What are they, and how to write them

In Agile, we avoid exhaustive documentation with a little thing called user stories. While user stories themselves may seem short and unimpressive, their effect on how teams work is profound. Without the task of comprehensive documentation, teams are empowered to do their most impactful work faster than ever.

While it may be difficult for those used to creating comprehensive documentation to shift to writing brief user stories, this is a crucial point of adaptation if you want to truly be Agile. Remember, according to the Manifesto, ‘working software‘ is always more important than ‘comprehensive documentation. ‘

Creating user stories

User stories are quite simple to construct. All you need is a description of a feature or requirement of a project. They can be written out on sticky notes, index cards, or an online whiteboard.

They are generally written from the perspective of the user. A simple format to follow would be:

• As a < type of user or role >, I want < goal > so that < reason >.

This answers three basic questions: who, what, and why. Without all three, the team will not be able to deliver a proper solution.

For logistical purposes, also include:

• A title and/or ID for the story
• Acceptance criteria (i.e. “I am done when…”)
• Priority
• Estimate points
• Category (i.e., payments, account, etc.)

All of the above information should be written out on your card. However, stories are not simply documents; they are conversations. The team is to write stories in person, and the Product Owner facilitates them.

Making great user stories

There are a few other considerations you should have when creating a user story. As you refine the details, you can follow the INVEST model, which means each story should be:

Independent: Reduce dependencies as much as you can to make things easier to plan.
Negotiable: The end result should be a collaboration between team members and the Product Owner.
Valuable: Each story must provide value to the customer and business.
Estimable: The better estimate you can provide, the easier it will be to split among team members.
Small enough: Each story should be able to be completed in less than a week by the team.
Testable: Your acceptance criteria should properly validate the story when all tasks are complete.

An example

Here’s an example of a proper user story:

As a user, I want to be able to add a comment to an issue so I can give feedback and important information to the team.

Acceptance criteria
The user needs to enter text into the comment field.
If the user clicks “Save,” the data should appear in the issue’s comments section.
If the user clicks “Cancel,” the data entered is refreshed, and the fields are cleared.

Why make user stories?

User stories act as a strong focal point for your team. By adding this step into your process, your team will always have something to refer to to ensure their work is serving the end user. Plus, your user story is an easy-to-access to-do list. When the whole team can see a high-level goal, they will be able to come up with more critical or creative solutions to arrive at their endpoint.

User story tools

The more user stories your team creates together, the better they will get at defining their story and acceptance criteria. The more the team works together, the better they will get at estimating work and delivering that work on time. As with anything, practice is the key to making user stories an asset to your team’s workflow.

Combine these tips with the right online whiteboard and project management tool, and your team will be ready to tackle any project.

This post was originally published on July 23, 2018, and updated most recently on March 13, 2021.