User stories are the building blocks of agile development. They show the objectives of a project in a user-centered way, making these objectives accessible to both stakeholders and team members.

Essential Parts of a User Story

As a [role], I want to [goal] so I can [motivation].
  1. The user’s ROLE

    Each type of person who uses your product has a unique workflow and set of needs, so it’s important to read stories in the right context. Roles don’t have to be limited to end users—you can also write stories for internal users who have needs surrounding the ability to deliver the best possible experience.

  2. The user’s GOAL

    The goal frames a user’s problem in the positive language of a desired objective. Describe the goal in a clear and concise way so everyone on the team can refer to it for the life of the project. If team members or stakeholders have difficulty understanding the goal, adjust the wording until it makes sense.

  3. The user’s MOTIVATION

    The reason why a user wants to accomplish a goal provides context for readers and establishes justification for including a story in the project. It also drives an informed solution to the problem by providing the team with the knowledge they need to choose the best possible solution for the user.

Metrics for Evaluating User Stories

Metric #1: The team can demonstrate the story with an objective measurement of success.
As a product owner, I want to easily calculate velocity so I can accurately plan releases.

Some stories attempt to communicate an experience rather than a specific objective. You can often spot this type of problem with the presence of adjectives like easily and quickly. The quality of the user’s experience should be considered when evaluating the solution for every story rather than standing alone as a goal. For this example, the team could not demonstrate successful completion of the story without a subjective evaluation from the product owner.

To improve stories without clear metrics for success, adjust the user’s goal to focus on a specific problem. You may need additional stories or user roles to accomplish the experience that you originally intended.

Here are two stories that the team could successfully demonstrate instead of the example above:

As a product owner, I want the team to estimate user stories with a defined scale so I can establish a reliable velocity.
As a UX person, I want consistent sprint lengths so I can plan for regularly-scheduled usability testing.

Metric #2: The story gives the team flexibility to choose from a variety of effective solutions.
As a developer, I want thorough UI specifications so I can plan my code correctly.

Sometimes a particular solution becomes ingrained in organizational thinking or simply seems like the only viable option. Look out for this trap to avoid placing constraints on the team. In this example, the goal implies that up-front specifications are the only solution for developers frustrated by lack of information.

Take a step back and identify the problem driving the suggested solution. Here, the problem could be that developers feel that the current specifications stand in the way of proper planning because they don’t account for technical limitations. Or, it could be that developers don’t have a way to get reliable answers to the questions that come up when coding.

Splitting the example above into these two stories would remove the constraints of a specific solution:

As a developer, I want to be involved in planning so I can share technical limitations that may impact the design.
As a developer, I want a resource with the power to make decisions so I can deal with obstacles that come up.

Metric #3: The story empowers the team to make informed decisions.
As a stakeholder, I want to know what the team is doing.

Stories with an unclear or non-existent motivation often stem from client requests that are passed on without proper context. If you can think of several vastly different ways to implement a solution to the problem, the story is probably too vague for the team to make a good decision. For this example, you could give the stakeholder access to your ticket tracking system, send a weekly email with a progress update, or install a live feed of the team’s workspace.

It’s easy to fix this type of problem. Just initiate a conversation with the user that goes something like this, “Can you tell me a story about a time when you had that problem?” This will put the request in context so you can clarify the motivation.

One or both of the following stories would provide additional information for the example above:

As a stakeholder, I want to see progress after each iteration so I can contribute my expertise to correct problems.
As a stakeholder, I want to know about how long a project will take so I can set expectations for my clients.

1 Comment

Comments are closed.