User Stories and Backlogs

The user story is the most common backlog-item format. It is not the only format, and the Scrum Guide does not require it. But teams find it valuable because it focuses on user value rather than technical tasks.

The Story Format

As a <type of user>
I want <some action or feature>
so that <benefit or outcome>.

Examples:

• "As a returning customer, I want to save my shipping address so that I do not have to re-enter it on every order."
• "As an admin, I want to bulk-deactivate users so that offboarding takes minutes instead of hours."
• "As a free-tier user, I want to see remaining quota so that I am not surprised by a paywall."

The format is a tool, not a constraint. If a sentence reads more clearly without the template, drop the template.

Why the Format Helps

• Who forces you to identify the user. "Everyone" is rarely the right answer.
• What describes the desired capability — not implementation.
• Why exposes the underlying need, often revealing simpler solutions.

The "so that" clause is often skipped — and it is the most valuable part. A story without a "why" cannot be challenged, prioritised, or simplified.

The 3 Cs

From Ron Jeffries:

• Card. The story title and short description; a placeholder, not a spec.
• Conversation. The detailed understanding lives in dialogue between team and Product Owner, not in the ticket text.
• Confirmation. Acceptance criteria define how to verify the story is done.

INVEST

A useful quality bar for stories:

If a story fails INVEST, refine it before pulling it in.

Acceptance Criteria

The conditions that must hold for the story to be accepted as done. They make "done" objective.

Format 1: Checklist

- Address book lists all saved addresses
- User can mark one address as default
- Selected default is pre-filled at checkout
- Editing an address persists across sessions

Format 2: Given / When / Then (Gherkin)

Given a logged-in returning customer with a saved default address
When they reach the checkout page
Then the default address is pre-filled
And they can change it before placing the order

Gherkin pairs naturally with automated acceptance tests.

Splitting Stories (Vertical Slicing)

A common mistake: split by layer. "Story 1: backend API. Story 2: frontend. Story 3: tests." Each one alone is useless; only their combination is shippable. Stories should split vertically — each is a thin slice through all layers, end-to-end useful.

Splitting techniques

• By workflow steps. Sign up → confirm email → onboarding → first action. Ship one step at a time.
• By data variations. Support credit cards first, then PayPal, then Apple Pay.
• By rules. Happy path first; edge cases as separate stories.
• By interface. Web first; mobile native later.
• By performance level. "Works correctly" first; "fast" as a follow-up story.
• Spike then build. Time-boxed investigation if too unknown to estimate.

Healthy Backlog Properties

Refinement

Ongoing activity, typically 5–10% of capacity. The team and Product Owner together:

• Clarify items.
• Split large items.
• Add or sharpen acceptance criteria.
• Estimate.
• Add or remove items.

Aim to keep at least the next Sprint's worth of items in "Ready" state.

Definition of Ready (Optional)

Some teams use a Definition of Ready for backlog items: small enough, INVEST-checked, acceptance criteria written, dependencies clear. Used carefully it raises planning quality; used as a gate it slows the team and creates mini-Waterfall.

Anti-Patterns

• Story as task list. "Implement endpoint X" is not a user story — there is no user, no value, no testable outcome.
• Cathedral stories. 200-word stories with implementation embedded. Should be a card and a conversation.
• Bug ≠ story. Don't dress bugs as user stories. Track them as bugs and prioritise them in the same backlog.
• Story bloat. Stories that take three Sprints to finish — split.

Cert Mapping

The next lesson covers estimation and velocity — how teams forecast without pretending to predict the future.