User stories: What are they, and how to write them
March 13, 2021
This post was originally published on July 23, 2018, and updated most recently on March 13, 2021.
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, it’s a crucial point of adaptation if you want to truly be Agile. Remember, ‘working software‘ is always more important than ‘comprehensive documentation,’ according to the Manifesto.
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 the digital program of your choice.
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…”)
- Estimate points
- Category (i.e., payments, account, etc.)
All of the above info should be written out on your card. However, stories are not simply documents; they are conversations. Stories are to be written in-person by the team and facilitated by the Product Owner.
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.
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.
The user needs to enter text into the comment field.
If the user clicks “Save,” then the data should appear in the comments section of the issue.
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 a reference to go back to and make sure 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.
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.