Skip to content
Software Architecture Guide

User Story Role Formulation

Explanation

Section titled “Explanation”

A user story is a short statement of something a user needs from a system. The role formulation gives it a fixed shape: a role, a need or want, and a reason or benefit. In template form: “As a [role], I want [function], so that [benefit].”

Where it comes from. This template started with an agile coach at a UK company called Connextra in the early 2000s.

The role. The first part names who wants the function. Teams often fall into starting every story with “As a user”. That generic label tells the team little. Name the real kind of person who will use the feature instead.

The function. The middle part says what the role needs or wants to do.

The “so that” clause. The last part gives the reason or benefit. It is often the most valuable part of the story. It shows the decision behind the request. That reason can change the design, the priority and the scope of the work. It is described as the most important part of a story, yet it should not be mandatory.

Confirming the story. Confirmation, expressed as acceptance criteria, tells the team how to know a story is complete. See the articles Card, Conversation, Confirmation and Acceptance Criterion.

Not everything is a story. Some technical work is clearer as a plain technical backlog item. Do not force it into the template.

Example

Section titled “Example”

A team building a recipe website might write:

“As a home cook, I want to filter recipes by cooking time, so that I can find a meal that fits the time I have tonight.”

The role is a home cook, not “a user”. The reason shows that speed matters. That could affect how prominent the filter is and how many filters the team builds first.

A task such as upgrading a database version would stay a technical backlog item. It does not need a role.

Trade-offs

Section titled “Trade-offs”

The “so that” clause adds effort to every story, and writers may fill it with empty phrases. Cohn says it should not be mandatory, so teams can leave it out when the reason is obvious. The template also does not fit all work. Forcing technical tasks into it makes them less clear.

Checks

Section titled “Checks”
  • Stories name a specific user role instead of starting generically with ‘As a user’.
  • Each story states a reason or benefit, or the team has chosen on purpose to omit it.
  • Each story has acceptance criteria that show how the team will know it is complete.
  • Purely technical work is kept as technical backlog items, not forced into story form.
Section titled “Related”

Sources

Section titled “Sources”