Overview

A user story is a short, simple description of functionality that has value to a user. A common template used to write user stories is: found below.

As a [blank], I want [blank] so that I can [blank].

The user story will serve as the placeholder for the feature requirement in the product backlog and should be bolstered by:

• Eliciting conversation between the product owner and Agile team.
• Adding acceptance criteria to foster understanding of when the user story will be considered done and how to verify it.
• References to supplemental documentation, including but not limited to wireframes, workflow representations, spreadsheets, etc.
• Estimates for relative level of effort.

Conversation

While the user story represents a user’s desired feature, a conversation must follow which serves to flesh out the details. The conversation should include the product owner, representing the interests of the user, and the Agile team, who will perform the work. The conversation will help establish common understanding across the team and produce acceptance criteria and possibly supplemental information.

Acceptance Criteria

As the product owner and Agile team converse about the details of a user story, they will begin to capture user expectations for the outcome of the user story. These expectations can be captured as acceptance criteria which allow the team to understand how to verify the user story and when to consider it done.

Supplemental Information

In addition to acceptance criteria, the team may create supplemental documentation in order to further clarify the user expectations for the new functionality. This could include diagrams for workflows, spreadsheets with calculations or mock-up sketches. The user story remains the central focus but can point to the supplemental information as required.

Estimate

For iteration and release planning purposes, user stories should be prioritized in the product backlog according to value and cost. The highest value, lowest cost features should be prioritized first. To support prioritization and iteration planning, user stories should contain an estimate for the level of effort (cost) required to implement the user feature.

The team should assign a value representing a relative (dimensionless) level of effort. This value is commonly known as the story point. One method to establish a consensus for the story point value is planning poker. The Agile team discusses the feature described by the user story and, when all questions are resolved, each team member privately selects a value, limited to those present in the Fibonacci sequence (1, 2, 3, 5, 8…). All team members present their selection. The team then discusses any discrepancies and repeats the voting until consensus can be reached.