Write User Stories That Pass INVEST — Requirements Engineering, Part 3

Requirements Engineering · Part 3

"As a user, I want a better refund process" survives grooming because nobody can disagree with it. It gets estimated as a five, sits in a sprint, and comes back with the question refinement should have asked: better how, and for whom?

INVEST — Bill Wake's 2003 checklist — catches that before the sprint rather than during it. This is the hands-on version: take one flow from the use case you documented in Part 2, write a story from it, run the six criteria against your own words, and read a verdict. For the template's anatomy see the plain-English version; for diagnosing a story already stuck, see the INVEST criteria guide.

Illustrative composite continuing the support-tooling example from Parts 1–2. Figures are illustrative, not measured.

Before You Start

• The Process a Refund Request use case from Part 2 — main flow numbered, alternate and exception flows given IDs.

• Your Part 1 interview notes, specifically the roles the support lead named.

• One real backlog item, in its current wording, that this use case is meant to satisfy. Don't clean it up first.

• Fifteen minutes with an engineer at the end. Schedule it now; step 8 needs a second person.

Budget 75 minutes for the first story, 15 for each after it.

What You'll Build

One user story written from a named flow, with acceptance criteria that trace to numbered steps, plus written INVEST verdicts on the draft and the rewrite — so you can see which letters moved and what moved them.

Step 1: Pick One Flow, Not the Whole Use Case (5 min)

Ours has a main flow (agent approves a full, in-window refund), A1 (partial refund), A2 (outside the 30-day window, needs a supervisor), E1 (gateway declines), E2 (original card closed). Take the main flow first — highest volume, fewest arguments.

Check: you can say out loud which flow ID your story covers. If the honest answer is "most of it," you have a use case wearing a story's clothes.

Step 2: Write v1 in Your Backlog's Real Voice (5 min)

Don't write the good one yet. Copy the actual backlog item, or write it the way your team does at 4:40 on a Friday. Ours:

v1: As a user, I want a better refund process so that refunds are easier.

Check: your v1 contains at least one of user, better, easier, improve. If not, you refined it on the way in — go get the original wording. This exercise needs something that fails.

Step 3: Replace the Actor With a Role Someone Holds (5 min)

"User" is the word a story uses when nobody has decided who it's for. Part 1's notes name three roles: Tier-1 agents working the queue, Tier-2 handling escalations, a supervisor approving exceptions. Only one appears in the main flow.

Check: the actor is a job title someone in your organization holds, and you can name the person. "Customer" counts; "user," "stakeholder," and "the business" do not.

Step 4: Run the Six Against v1 and Write the Verdicts Down (15 min)

Ask each as a yes/no question and write the reason beside the answer. In writing: the point is the diff you read in step 5.

• I — Independent: can this ship without another story shipping first?

• N — Negotiable: does it name what, leaving how to the team?

• V — Valuable: who is better off, and how would they notice?

• E — Estimable: could the team put a number on it today?

• S — Small: does it fit one sprint with room to be wrong?

• T — Testable: is there an observation that settles "done"?

Check: six written verdicts, at least two of them "no" with a stated reason. Six yeses on a v1 written in step 2 means you graded the story you meant, not the story you typed.

Step 5: Rewrite to v2 and Re-Run the Six (20 min)

The main flow's step 3 has the agent compare refund amount against order total, purchase date against the window. That comparison is the decision, and the data it needs is the story.

v2: As a Tier-1 support agent, I want the refund queue list to show order total, requested refund amount, and days since purchase for each request, so that I can approve in-window full refunds without opening each order.

Re-run all six side by side. This grid is the artifact worth keeping, because it shows which letter each edit bought:

INVEST	v1 fails because	v2 passes because
I — Independent	"Refund process" pulls in queue, gateway, and email — three teams, sequenced	Reads three fields already on the order record; ships alone
N — Negotiable	No what to push back on	Names the fields and the outcome, not the layout or the component
V — Valuable	"Easier" for an unnamed person	A named role stops opening every order to make one decision
E — Estimable	Any number is defensible, so none is real	Bounded to one list view, three known fields
S — Small	Unbounded; could absorb the quarter	One screen, one flow, one release
T — Testable	No observation settles it	Open the queue, read a row: the fields are there or they aren't

Check: every letter reads "passes," and for each you can point at the words in v2 that earn it. A pass you can't point at is a pass you assumed.

Step 6: Derive Acceptance Criteria From the Flow's Steps (15 min)

Don't invent criteria. Walk the numbered steps of your flow and turn each one the story touches into a condition:

• Each row displays order total, requested refund amount, and days since purchase.

• Days since purchase is calculated from order date, not request date.

• Requests where refund amount equals order total are distinguishable from partial ones.

• An agent can approve from the list view without opening the order.

• Approving from the list view writes the same audit record as approving from order detail.

Working heuristic, not a rule: three to seven criteria is usually the band where a story is specific enough to test and small enough to finish. Under three is underspecified; over seven is usually two stories. Investigate the count; don't enforce it.

Check: every criterion traces to a numbered step or named flow in Part 2, and none names a UI control ("dropdown," "modal," "toggle"). Naming a control moves the design decision into the requirement.

Step 7: Split on Flow Boundaries, Not on Effort (10 min)

A1, A2, E1, and E2 are not criteria on this story. They're separate stories — different actor, different value, different way to be wrong. A supervisor approving an out-of-window refund is not the conversation an agent has approving an in-window one. Split on boundaries the use case already drew.

Check: one story per flow ID, and no story cites more than one. A story citing two means you split on effort ("part one, part two") rather than behavior, and neither half is independently valuable.

Step 8: Read It to an Engineer Before Sprint Planning (15 min)

Read the story and criteria aloud, ask them to restate it, then ask the question that matters: what would you have to decide that I haven't written down?

Everything they name goes somewhere. Conditions specific to this story become acceptance criteria. Conditions true of every story — logging, error handling, accessibility conformance, coverage — belong in the definition of done. No written definition of done? That's the gap this step found.

Check: the engineer restated the story without adding a condition you hadn't written, or you captured the ones they added. An unrecorded verbal clarification is a defect scheduled for the demo.

If This Goes Wrong

• Every letter passes on the first try. You graded the story you intended, not the one on screen. Hand v1 to someone who wasn't in the interview and have them answer the six.

• You're at fifteen acceptance criteria. The story is too big. Don't trim criteria — that hides the size instead of fixing it. Split on a flow boundary and they distribute themselves.

• It passes Independent only if two things ship together. Then it doesn't pass. Sequence them as an explicit dependency, or find the thinner slice — usually the read-only version.

• The actor is "the system." That's a technical task. Keep it, but attach it to the story it enables so its value stays traceable.

• You can't write a testable so that. Go back to the interview notes, to where the support lead named the cost of going without it.

Common Failure Modes

• Implementation as criteria — the story names the control, leaving nothing to negotiate.

• The generic actor — "as a user" passes review and fails the demo.

• The decorative so that — a benefit clause with no benefit in it.

• Criteria from imagination — nothing traces back to the use case, so nothing traces forward to a test.

• Splitting by layer — "backend story" and "frontend story" are halves of one, and neither ships.

You're Done When

1. Every story names a flow ID from Part 2, and every flow ID is claimed by exactly one story.

2. Each story carries a written INVEST verdict with six explicit answers, every one "yes" for a reason you can point to in the text.

3. An engineer outside the requirements sessions restated one story's scope correctly, raising no question you hadn't answered in writing.

Then the stories are ready for Part 4, where you trace them back to the original requests — which is where you find out whether anything the support lead asked for in Part 1 quietly failed to become a story.

Sources

• Bill Wake, "INVEST in Good Stories, and SMART Tasks," xp123, August 17, 2003 — https://xp123.com/invest-in-good-stories-and-smart-tasks/