Writing User Stories

An important part of the agile methodology revolves around writing user stories.

What are user stories?

User stories consist of one or two sentences used to describe a feature from the perspective of an end user. Their purpose is to capture what the user wants and why, which is the reason they are written in everyday language.

They usually follow this template:

As a <user type>, I want <feature/function> so that <benefit>.

Other important elements of a user story are the acceptance criteria and the size. The acceptance criteria are the conditions that need to be met for the story to be considered as complete and accepted by the user and the stakeholders. User stories commonly include 3 or more acceptance criteria. They make the user story more understandable by defining its boundaries.

Size makes reference to the level of complexity of a story and the effort needed to implement it. Teams estimate the size by assigning story points or hours of work to each card. A good practice is to make these estimations as a team in order to reach a consensus and obtain accurate estimates. A popular estimating technique is planning poker, in which team members use numbered cards to make their estimations. Each member picks a card whose number represents the amount of effort needed for a particular story, and when everyone is ready the cards are shown and discussed in order to reach consensus. There are several tools that enable teams to do planning poker sessions virtually.

When and where are they written?

Generally, user stories are written at the start of the project in order to create a backlog of all the functionalities that will be added in a release cycle. Nevertheless, they can also be added to the backlog throughout the duration of the project as needed.

Before writing them, the team needs to research the end users of the system to know who they are and what are their needs. Interviewing these users is key to understanding their real concerns and expectations, and provides the team with a better picture of what needs to be built.

Most commonly, teams write their user stories on sticky notes or paper cards. Keeping them visible helps the team focus on what needs to be done, so many teams display them at a nearby wall.

Who writes them?

Any member of the agile development team can write user stories. Some teams even write them collaboratively, since this enables their discussion. Having a conversation about the features helps the team properly define what these involve and their priority during the sprint.

As mentioned above, it is important to involve the users and stakeholders of the system in the process. Since they are subject matter experts, letting them write the stories is a good tactic.

Level of detail

When a user story is too large to be completed in a single iteration, it is considered an epic. Epics can be broken down into several smaller user stories. By doing this, agile teams can work on simpler and more detailed stories that can be completed during a sprint.

Writing good user stories

Remember the following things when writing user stories:

• Keep them simple and understandable
• Be precise
• Must be written from the perspective of a user
• Should be written collaboratively
• Discussing them as a team is key
• Keep them visible
• They must be achievable inside a sprint
• Size and acceptance criteria must be defined

If you need more guidance to get started, you can download this helpful template for user stories created by craig brown.

Twitter: @planwcards

Email: hello@planningwithcards.com