User Story Format Explained

In Scrum, all the items in the product backlog are called product backlog items (PBIs). PBIs represent statements of need to create or improve the product. However, we often hear teams refer to the items in the product backlog as user stories or stories. A user story is a format to write PBIs. Scrum does not specify that you must use the user story format either. This means Scrum teams are free to use whatever format they wish, such as user stories, use cases, or even shall statements. In other words, every user story is potentially a product backlog Item, but not all PBIs have to be expressed as user stories.

While there are several variations of the user story, the most common format is the Connextra format. The Connextra format, as created in 2001 by Rachel Davies, follows the following format:

As a {user}

I want {capability/request}

So that {value}

In the past, line item “shall statements” were very popular. The shall statement is a simple statement of need. For example, “the house shall have a new hardwood floor.” In using the Connextra format, the statement could be written as:

As a homeowner

I want a new hardwood floor

So that my floors will look like they did the day I bought the house

In that statement, we know that the target user for this request is the homeowner, the capability/request is the new hardwood floor, and the value is they want it to look like it did when they bought the house.

Once the developer understands the user story, especially the value statement, they can look past simply the statement of need and more at the desired value. In this case, the developer may say, “We could give you the new hardwood floors like you requested. It’ll be $13,000 and three weeks’ worth of work. These floors appear to be original to the house and its very nice wood, though quite weathered. An alternative to the new hardwood floor is that I can sand it down and refinish it. It’s going to be the same floors you have now, but it’ll look like new. That job would cost $3,500 and take one week of work. Let me know which option you prefer.”

Once the developer understands the value of the user story, they can innovate on potential alternative solutions that may be better, faster, or more effective than what was originally written.

Additionally, when a developer reads this user story, one of the things they might realize is that they have no idea what the floors looked like when the homeowner bought the house. This calls out a need for acceptance criteria. The acceptance criteria are the conditions of satisfaction for the user story. Consider this acceptance criteria for the hardwood floor user story:

• Floor has a shine

• Minimal scratches

• Deep color

The problem here is that these points are too subjective. What does shine mean? What’s minimal? What’s deep? We want to write our acceptance criteria to be less subjective and more objective. The statements below work much better as our acceptance criteria:

• Brown

• Maple Rio Grande – 5 inch

• No scratches larger than 1 inch

• No more than 1 scratch per sq foot

You can go to a Lowe’s or Home Depot and if the box of hardwood floor is labelled “brown, Maple Rio Grande – 5inch,” then it’s the right product. If the box of hardwood floors does not say that, then it’s not the right product. You can get a ruler and identify if the last two bullet points about the scratches are true or false. This makes the acceptance criteria less subjective and more objective.

In terms of the user, we want to target a role as close to the end user as possible. The user is not instructions to the team. Below are some anti-patterns to look for regarding user types:

• As a user (too generic)

• As an app user (too generic)

• As a tester (avoid making it instructions to the team)

• As a developer (avoid making it instructions to the team)

• As a Scrum Master (avoid making it instructions to the team)

In terms of the user, it’s important to focus on a type of user for that request. For example, let’s say the user story was focused on a home flipper. The developer would know that the home flipper would want the job done quickly and would want to save cost, but the floor would need to look good and the materials would need to appeal to the type of buyer the home flipper was targeting. Alternatively, if the user was someone who was going to live there the rest of their life, then they may be willing to spend more if the desire for the material and long-term durability justifies the cost.

The great advantage of the user story is that it moves our requirements away from simply statements of need, towards a true story about who the user is, what they desire, and why they want it. This allows our teams to have a greater understanding of their users and the user’s true needs.

To learn more about user stories and product backlog items, join us in our Certified Scrum Product Owner training course.