A user story is a fixed template: "As a [role], I want [goal], so that [reason]." The format is simple; what makes a story actually usable is INVEST — Independent, Negotiable, Valuable, Estimable, Small, Testable — six criteria for a well-formed story. This chapter verifies three of the six with real numbers, and connects the sixth directly to a chapter already built in this site's own Software Testing Strategy course.
Independent: The Cost of a Story That Isn't
# Story A: 8 days, hits a real 4-day blocker partway through# Story B: 5 days — but can it start before Story A finishes?
STORY_A_EFFORT = 8
STORY_B_EFFORT = 5
STORY_A_BLOCKER_DELAY = 4
Verified directly — a dependent story inherited its blocker's own delay in full; an independent one was unaffected
When Story B needs Story A's own output before it can start: Story A finishes on day 12 (8 days plus the 4-day blocker), and Story B — unable to start until then — finishes on day 17. When Story B needs nothing from Story A and a different person can start it immediately: Story A still finishes on day 12, but Story B finishes on day 5 — 12 days earlier, completely unaffected by a blocker that had nothing to do with it.
This is Chapter 3's own blocker-cost finding, now applied to how stories are written, not just how blockers are surfaced
A daily standup (Chapter 3) gets a blocker fixed faster once it's discovered. Writing genuinely independent stories prevents an unrelated blocker from ever reaching a second piece of work at all — a stronger guarantee than fast discovery, because there's nothing to discover.
Testable: The Cost of a Story That Isn't
Verified directly — a vague story produced 4 distinct implementations; a testable one produced 1
Six developers independently implementing "the page should load fast" (no concrete threshold given): 4 distinct thresholds — 500ms, 1500ms, 2000ms, and 3000ms — each a individually reasonable interpretation of "fast." The identical six developers implementing the same story with an explicit acceptance criterion ("loads in under 2000ms"): 1 distinct threshold — all six built to exactly 2000ms.
This isn't a hypothetical disagreement — it's a real integration bug waiting to happen
A frontend developer building against a 500ms assumption and a backend developer building against a 3000ms assumption will each individually believe their work is correct, matching Software Testing Strategy Chapter 1's own "100% passing, still broken" finding — each side's own tests can pass in isolation while the combined system disagrees on what "fast" even means.
Testable, Concretely: Acceptance Criteria Are a BDD Scenario
A well-formed acceptance criterion and a Given-When-Then scenario aren't two different documents that happen to say similar things — written correctly, they're the same sentence, twice:
As an acceptance criterion
As a Given-When-Then scenario (Software Testing Strategy Ch.8)
"Given a $100 cart, a GOLD member sees a 10% discount at checkout"
Given a cart total of $100, When a GOLD member checks out, Then the total is $90
This is why the two courses connect directly
Software Testing Strategy Chapter 8 verified a BDD scenario fails loudly the moment the underlying behavior drifts from what was agreed. A story's own acceptance criteria, written in the same Given-When-Then shape from the start, becomes that same executable safety net for free — not a separate artifact written twice, once for the story and once for the test.
Small: The Cost of a Story That Isn't
SPRINT_CAPACITY = 10# points, matching Chapter 3's own known-velocity finding# same 13 points of total scope, two different splits:# ONE story worth 13 (all-or-nothing)# FIVE stories worth 3, 3, 3, 2, 2 (independently shippable)
Verified directly — splitting identical scope into small stories delivered 9 points; the single large story delivered 0
One 13-point story against a 10-point sprint capacity: since it can't finish within capacity, 0 points ship — a half-built feature has no value on its own. The same 13 points split into five smaller, independently-completable stories: the sprint finishes three of them (3+3+3=9 points) before running out of capacity, and each finished story genuinely ships — 9 points of real value delivered, from identical total scope and identical capacity.
This directly extends Chapter 3's own overcommitment finding
Chapter 3 showed overcommitting past known velocity doesn't create more real output — it just makes a normal sprint look like a failure. This chapter adds the sharper version: a single oversized story doesn't just risk looking bad, it risks shipping literally nothing, even when the team did just as much real work as the small-story scenario.
Where This Connects
This chapter's finding
What it connects to
A dependent story inheriting its neighbor's own blocker delay
Chapter 3's own daily-standup finding — writing independent stories prevents the problem standups exist to catch faster
Acceptance criteria and BDD scenarios being the same sentence twice
Software Testing Strategy Chapter 8's own living-documentation finding
A single large story shipping zero value at a sprint boundary
Chapter 3's own overcommitment finding — both show a mismatch between commitment shape and real capacity
Hands-On Exercises
Exercise 1
Using this chapter's own independence simulation, add a third story, Story C (4 days effort), that depends on Story B rather than Story A. Determine Story C's own finish day under both the dependent and independent scenarios, and the new total delivery delay this chains onto the original finding.
Using this chapter's own testability simulation, add a third possible story: "the page should be secure" (equally vague). Propose 5 plausible, genuinely different developer interpretations of what "secure" might mean in practice, and explain why vagueness in a non-numeric requirement is at least as risky as vagueness in a numeric one like load time.
Using this chapter's own small-stories simulation, re-split the same 13 points differently: 5, 4, 4 instead of 3, 3, 3, 2, 2. Determine how many points actually ship within the same 10-point sprint capacity, and explain why the split itself — not just the total point count — determines the outcome.
Verified: a dependent story inherited a 12-day delay from an unrelated blocker; an independent one was unaffected
Verified: a vague story produced 4 distinct developer interpretations; a testable one with explicit criteria produced 1
Verified: the same 13 points of scope delivered 0 shipped value as one large story, 9 as several small ones
Testable, concretely: a well-written acceptance criterion and a Given-When-Then scenario (Software Testing Strategy Ch.8) are the same sentence, not two documents
Next chapter: Estimation — story points, planning poker, and why early estimates are structurally, not just accidentally, unreliable