User Stories

A user story represents a small piece of business value that a team can deliver in an iteration. 

A user story is defined incrementally, in three stages:

1. The brief description of the need
2. The conversations that happen during backlog grooming and iteration planning to nail down the details
3. The tests that confirm the story's satisfactory completion

Bill Wake has given us the INVEST mnemonic to help remember the characteristics of a well-formed user story:

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

Why use user stories?

1. Expressing business value
2. Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution
3. Avoid the appearance of false completeness and clarity
4. Get to small enough chunks that invite negotiation and movement in the backlog

How do I write user stories?

As a <user type>, I want to <function> so that <benefit> 

Examples:

As a business consultant, I want to know which tasks I own so that I can decide what to work on now.

Try to avoid the generic role "User" when writing user stories. User stories are about all of the "actors" who interact with the system or who realize some value or benefit from the system. Not all actors are end users.

What size should a user story be?

A story should be small enough to be coded and tested within an iteration- ideally just a few days. When a story is too large, it is called an "epic". Backlog items tend to start as epics, when they are lower priority. 

How detailed should a user story be?

Too broad

"A team member can view iteration status."

Too detailed

"A team member can click a red button to expand the table to include detail, which lists all the tasks, with rank, name, estimate, owner, status."

Just right

"A team member can view the iteration's stories and their status, with main fields."

"A team member can view or hide the tasks under the stories."

"A team member can edit a task from the iteration status page."

How do we know when we’re missing the mark? Ultimately “User stories are a promise for a conversation” (Ron Jeffries). If Product Owner and Team both know what they mean, you’re off to a good start. But you can probably save some time by avoiding the common pitfalls below:

“Design brochure layout.”

Drawbacks: not Independent, no business Value. This is a task representing a horizontal architectural layer or phase. The architecture will be done in a vacuum, possibly contributing to analysis paralysis.

Better: “As a dog owner, I can find a meal schedule on the brochure so I know whether this doggy day care center is appropriate for my hungry dog.”

This will lead to only the necessary amount of design to support this Sprint’s features. The layout might change the next Sprint, but rework is cheaper than no work.

“Write game rules.”

Drawbacks: not Independent, no business Value, not Small.

Better: “As a newbie game player, I want to know who goes first so we can start the game.”

Better: “As a competitive gamer, I want a way to leapfrog my opposing players.”

“I want the brochure to be colorful.”

Drawbacks: not Independent, not Estimable (without knowing other features of brochure), not Small.

This is an easy trap for those of us who grew up with the habit of writing “the JFIDM _shall_ comply with the IEEE-488 interface specification.”

Better: Use “colorful” and other cross-cutting requirements as acceptance criteria on each of the specific features in the backlog they apply to.

“As Product Owner, I want a list of highly-rated restaurants on the brochure.”

Drawbacks: It’s not only about you!

Better: Focus on your end users and stakeholders. “As a gourmet tourist, I want a list of highly-rated restaurants on the brochure.”

Better: “As the Chicago Public Health Department, I want warnings about restaurants that serve raw ingredients so that tourists don’t get sick on our dime.”

“Play test the game.”

Drawbacks: Not Independent. Encourages phase wise development.

Better: Make testing, refactoring, etc. a default acceptance criteria on every Product Backlog Item.

User stories are simple thing. “Simple” is often not the same as “easy.” Happy unlearning!