Lesson 23: User Stories

Lesson 22 ended with a well-formed PRD — problem-first, appropriately precise, genuinely collaborative. But a PRD describes a solution at the level of an entire feature or initiative; it does not, by itself, tell an engineering team what to build this week, or how to sequence work across a sprint. This lesson covers the artifact that closes that final gap: the user story, a small, specific unit of functionality described from the perspective of the person who benefits from it, sized to be independently implementable, testable, and deliverable within a short time frame.

A user story's format is famously simple — "As a [role], I want [capability], so that [benefit]" — deceptively so, because the format itself is not the hard part. The hard part, and this lesson's real subject, is splitting a larger scoped solution (an MVP, a PRD's functional requirements) into stories that are each genuinely independent, genuinely valuable on their own, and genuinely small enough to build and verify quickly — without splitting so finely that individual stories lose all standalone meaning, or so coarsely that a single story becomes an unmanageable, multi-week undertaking in disguise.

Learning Objectives

1
Write a user story using the standard format, and explain why each of its three clauses matters.
2
Apply the INVEST criteria to evaluate whether a candidate user story is well-formed.
3
Apply at least three specific story-splitting techniques to break a large story ("epic") into smaller, independently valuable stories.
4
Identify the "story as a disguised task" failure pattern and distinguish a genuine user story from a technical task wearing story-format grammar.
5
Distinguish appropriate story granularity from over-splitting, and explain the risks of each extreme.

Lesson 21 (MVP) and Lesson 22 (Product Requirements Document). This lesson assumes you can scope a minimal solution and write a clear functional requirement — a user story is the unit that breaks a PRD's requirements down into concretely sequenceable, implementable, and testable pieces of work.

The Standard Format and Why Each Clause Matters

The canonical user story format is: "As a [role/persona], I want [capability], so that [benefit]." Each clause serves a specific, deliberate purpose:

"As a [role]" ties the story back to a specific persona (Lesson 14) or user type, preventing the same undifferentiated "the user" language this curriculum has repeatedly warned against.
"I want [capability]" states the specific functionality being requested, at a level of granularity appropriate for a single, small unit of work.
"So that [benefit]" states the underlying value or job (Lesson 6) the capability serves — and this clause is frequently the most important, and most frequently omitted or treated as an afterthought, because it is what allows anyone reading the story (not just the person who wrote it) to judge whether an implementation choice actually serves the intended purpose.

A story missing the "so that" clause loses exactly the connective tissue that lets an engineer make good judgment calls on ambiguous implementation details — recall Lesson 22's Precision Dial: a well-specified "so that" clause is often what allows a PM to appropriately under-specify the "how," because the underlying reason gives the implementer enough context to make a sound decision independently.

The INVEST Criteria

A widely used, practical checklist for evaluating whether a candidate user story is well-formed is the INVEST acronym:

Independent: the story can be built and delivered without being blocked by, or tightly coupled to, other stories.
Negotiable: the story describes a need, not a rigid, final specification — the specific implementation remains open for discussion between the team members involved (directly echoing Lesson 22's Precision Dial).
Valuable: the story delivers genuine value to the named persona or the business, not merely a technical intermediate step (directly connecting to the next section's core distinction).
Estimable: the team can reasonably estimate the effort required to complete it, which requires the story to be specific and bounded enough to reason about.
Small: the story is sized to be completed within a short time frame (often within a single sprint, sometimes within a few days), not a multi-week undertaking in disguise.
Testable: there is a clear, verifiable way to determine whether the story has actually been completed (a concept extended fully in Lesson 24's acceptance criteria).

A story failing any single INVEST criterion is not necessarily useless, but should prompt specific attention: a story that isn't independent may need resequencing or restructuring; a story that isn't valuable may actually be a disguised technical task (see below); a story that isn't small may need splitting, which is the primary technique this lesson covers next.

Story-Splitting Techniques

The central practical skill in this lesson is splitting a large story (sometimes called an "epic" once it's clearly too large to be a single INVEST-compliant story) into smaller stories that each remain independently valuable. Several widely used techniques:

Split by workflow steps: if a capability involves a multi-step process, each step can sometimes become its own valuable story — for example, splitting "As a user, I want to book and pay for an appointment" into "As a user, I want to book an appointment" and "As a user, I want to pay for a booked appointment," provided each step delivers standalone value on its own (which should be checked, not assumed).
Split by business rule variations: if a capability has multiple variants or edge cases (different payment methods, different user permission levels), the core, most common case can become its own story, with variants split into subsequent stories — directly echoing Lesson 21's MVP discipline of testing the riskiest, most essential version first.
Split by data variations: if a capability must handle multiple types of input or data, the most common or simplest type can become its own story first, with additional types added incrementally.
Split by interface variations: if a capability needs to work across multiple platforms or interfaces (web, mobile, API), the primary platform can become its own story, with others following.

Crucially, every split must be checked against the INVEST criteria afterward, particularly Valuable and Independent — a mechanical split that produces a piece with no standalone value (for example, splitting a login flow into "build the username field" and "build the password field" as separate stories) has produced fragments, not genuine stories, echoing Lesson 21's car-wheel failure at the level of individual units of work rather than an entire MVP.

The "Story as a Disguised Task" Failure Pattern

A specific, common failure — closely related to Lesson 17's disguised-solution problem and Lesson 21's car-wheel failure — is writing something in user-story grammar ("As a [role], I want...") that is actually a technical task with no standalone value to the named persona, rather than a genuine, valuable capability. "As a developer, I want to refactor the authentication module" is grammatically a story, but names no benefit to an actual product user, and would fail the INVEST "Valuable" criterion when evaluated honestly against the persona it claims to serve.

This does not mean technical work (refactoring, infrastructure improvements, technical debt reduction — covered further in Lesson 39) is illegitimate or unimportant; it means such work should generally be tracked and communicated using language appropriate to what it actually is — a technical task, not a user story — rather than forced into story-format grammar that implies a standalone value to an end user that isn't actually present. Mislabeling technical tasks as user stories obscures the genuine distinction between value-delivering and infrastructure-supporting work, making it harder to have honest conversations about the trade-off between the two during planning and prioritization.

Common Mistakes to Avoid

Omitting or treating the "so that" clause as an afterthought

This clause provides the connective context that allows implementers to make good independent judgment calls on ambiguous details — omitting it removes exactly the information that would otherwise let a PM appropriately avoid over-specifying the "how."

Splitting a story mechanically without checking the result against INVEST, especially "Valuable" and "Independent.

A split that produces fragments with no standalone value (echoing Lesson 21's car-wheel failure) has not actually produced genuine, smaller user stories — merely smaller, disconnected pieces of a larger plan.

Writing technical tasks in user-story grammar without genuine standalone value to the named persona

"As a developer, I want to refactor X" is grammatically a story but fails the "Valuable" INVEST criterion when evaluated honestly — such work should be tracked and communicated as what it actually is.

Leaving a story too large ("Small" INVEST failure) because splitting feels like unnecessary overhead

A story that takes multiple weeks to complete is difficult to estimate accurately, difficult to prioritize meaningfully against other work, and delays the delivery of standalone value that a properly split version would have delivered incrementally.

Over-splitting a story until individual pieces no longer deliver standalone value

Splitting too finely — down to the level of individual UI elements or database fields — produces exactly the same "fragments without standalone value" problem as mechanical, uncritical splitting, just from the opposite direction.

Mental Model

The Story Value Test

This lesson's mental model is the Story Value Test — a quick check applied to any candidate user story, whether freshly written or the result of a split, before it's added to a backlog.

Apply this test to every candidate story: if it were the only thing shipped this sprint, with nothing else, would the named persona (or the business) genuinely be better off? If the honest answer is no — if the story only matters in combination with several other, not-yet-built pieces — the story has likely been split too finely, or was never a genuine story (a task in disguise) to begin with.

Quick Reflection Checkpoint

Key Takeaway: How will you apply "The Story Value Test" when evaluating trade-offs in your product decisions?

User Stories