User Story Chef
Write stories that minimize the cost of being wrong, not stories that look correct.
The Lie You Were Taught
Form: "As a [persona], I want [need] so that [benefit]"
Truth: The template is scaffolding for conversation, not the deliverable. A story following the template perfectly can be worthless. A story violating it can deliver more value.
What a User Story Actually Is
A user story is a unit of value negotiation with feedback mechanisms.
It is NOT:
- A requirement (it's a placeholder that defers detail until the team determines the timing is right)
- A specification (it's an invitation to discuss)
- A task (tasks decompose work; stories decompose value for users)
INVEST as Physics, Not Checklist
| Criterion |
Convention (Form) |
Truth (Function) |
| Independent |
"Stories shouldn't depend on each other" |
Enables parallel work and flexible prioritization -- coordination physics |
| Negotiable |
"Details can change" |
Preserves optionality until last responsible moment -- information economics |
| Valuable |
"Delivers user value" |
Produces measurable outcome -- enables prioritization |
| Estimable |
"Team can estimate it" |
Bounds uncertainty -- predictability for planning |
| Small |
"Fits in a sprint" |
Optimizes feedback loops -- smaller = faster learning |
| Testable |
"Has acceptance criteria" |
Creates binary completion state -- prevents ambiguity |
A story violating INVEST isn't "bad" -- it has suboptimal feedback characteristics. Fix the physics, not the form.
Acceptance Criteria as Hypotheses
AC are falsifiable hypotheses about value delivery.
Cook's AC (Form):
- User can click button
- System shows message
- Data saves to database
Chef's AC (Function):
Given [precondition that makes this valuable]
When [action that delivers the value]
Then [observable outcome that proves value was delivered]
Each criterion should answer: "If this passes but users still complain, what did we miss?"
Story Slicing
Split by value delivery, not by component or layer.
Wrong (component slicing):
- Build database schema
- Build API endpoints
- Build frontend form
Right (value slicing):
- User can submit simplest case (happy path, hardcoded everything else)
- User can handle rejection case (adds error value)
- User can see history (adds retrospective value)
Each slice is deployable and testable. Each delivers incremental value.
SPIDR Decomposition
Five techniques for splitting stories:
| Technique |
When to Use |
Example |
| Spike |
Uncertainty blocks estimation |
Extract time-boxed investigation; then build on the decision |
| Paths |
Multiple workflow variations |
Split "checkout" into: saved payment, new card, PayPal, failed+retry |
| Interface |
Multiple channels/devices |
Split "view dashboard" into: desktop, mobile, email summary |
| Data |
Varying data scope |
Split "export users" into: single user, filtered subset, all with progress |
| Rules |
Varying business rule complexity |
Split "calculate tax" into: single-state, exemptions, multi-jurisdiction |
Additional Slicing Patterns
- Workflow slicing: Decompose by stages of a user journey (initiate, review, input, choose, transact, confirm). Each stage is independently valuable.
- Data lifecycle slicing: Decompose by CRUD operations. Start with READ (proves data exists), then CREATE, then UPDATE/DELETE.
- Interface fidelity slicing: Decompose by interaction richness (exact match, fuzzy match, filters, sorting, suggestions). Each layer adds richness.
Validation Order
When multiple slices exist, order by:
- Highest risk -- validate assumptions that could invalidate everything
- Highest learning -- get feedback that informs remaining slices
- Highest value -- deliver what matters most if project is cut short
Every slice must be independently deployable and deliver observable value. Test: can a user tell the difference before and after this slice ships?
Anti-Patterns: Form Addiction Symptoms
When you see these, you're mimicking, not thinking:
| Symptom |
Diagnosis |
| Story fits template but team asks "what does this mean?" |
Card without Conversation |
| AC list technical steps, not user outcomes |
Implementation leaking into specification |
| Story can only be done by one specialist |
Sliced by skill, not by value |
| "As a developer, I want..." |
Story serves system, not user |
| Story takes multiple sprints |
Not a story -- it's an epic wearing a mask |
| Team debates story during implementation |
Insufficient Conversation before commitment |
Detailed Anti-Pattern Catalog
| Anti-Pattern |
Symptom |
Cure |
| Template Worship |
Follows template perfectly, team still asks "what does this actually mean?" |
Ask "what observable behavior changes?" and rewrite with specificity |
| Technical Story |
"As a developer..." or "As the system..." |
Find the user value it enables, or track as technical debt separately |
| Epic in Disguise |
Seems reasonable, takes multiple sprints, scope keeps growing |
Decompose by specific, completable sub-outcomes |
| Componentized Story |
Maps to technical layers (DB -> API -> UI), sequential dependencies |
Slice thin vertically through all layers; each slice delivers complete value |
| Orphan Card |
Card goes straight from backlog to sprint without refinement |
Require refinement session: team estimates without wild variance, edge cases identified, AC agreed |
| Implementation Leak |
AC describe HOW (calls POST /api/users, inserts row) not WHAT |
Rewrite AC as observable outcomes: "user sees confirmation", "user appears in admin list" |
| Moving Target |
Story changes during sprint, "one more thing" becomes three |
Stories freeze once committed; new requirements become new stories for future sprints |
| Checkbox AC |
AC test existence (button exists, button is blue) not function |
AC should be user-verifiable: "user submits form and receives confirmation within 3 seconds" |
The Chef's Protocol
- Start with outcome: What can users do afterward that they couldn't do before?
- Find the smallest slice: Identify the minimum that delivers that outcome
- Write AC as experiments: Specify how to prove the outcome occurred
- Use template if helpful: The format serves clarity, not compliance
- Invite conversation: The card begins discussion, not documentation
1---2name: user-story-chef3description: Writes user stories as value negotiation units, not template-filling exercises. Triggers: writing user stories, acceptance criteria, backlog items, story splitting, evaluating story quality, INVEST criteria application. Use when creating or refining Agile artifacts that capture work units.4---56# User Story Chef78Write stories that minimize the cost of being wrong, not stories that look correct.910## The Lie You Were Taught1112**Form:** "As a [persona], I want [need] so that [benefit]"1314**Truth:** The template is scaffolding for conversation, not the deliverable. A story following the template perfectly can be worthless. A story violating it can deliver more value.1516## What a User Story Actually Is1718A user story is a **unit of value negotiation with feedback mechanisms**.1920It is NOT:21- A requirement (it's a placeholder that defers detail until the team determines the timing is right)22- A specification (it's an invitation to discuss)23- A task (tasks decompose work; stories decompose value for users)2425## INVEST as Physics, Not Checklist2627| Criterion | Convention (Form) | Truth (Function) |28|-----------|-------------------|------------------|29| **Independent** | "Stories shouldn't depend on each other" | Enables parallel work and flexible prioritization -- coordination physics |30| **Negotiable** | "Details can change" | Preserves optionality until last responsible moment -- information economics |31| **Valuable** | "Delivers user value" | Produces measurable outcome -- enables prioritization |32| **Estimable** | "Team can estimate it" | Bounds uncertainty -- predictability for planning |33| **Small** | "Fits in a sprint" | Optimizes feedback loops -- smaller = faster learning |34| **Testable** | "Has acceptance criteria" | Creates binary completion state -- prevents ambiguity |3536A story violating INVEST isn't "bad" -- it has suboptimal feedback characteristics. Fix the physics, not the form.3738## Acceptance Criteria as Hypotheses3940AC are falsifiable hypotheses about value delivery.4142**Cook's AC (Form):**43```44- User can click button45- System shows message46- Data saves to database47```4849**Chef's AC (Function):**50```51Given [precondition that makes this valuable]52When [action that delivers the value]53Then [observable outcome that proves value was delivered]54```5556Each criterion should answer: "If this passes but users still complain, what did we miss?"5758## Story Slicing5960Split by value delivery, not by component or layer.6162**Wrong (component slicing):**631. Build database schema642. Build API endpoints653. Build frontend form6667**Right (value slicing):**681. User can submit simplest case (happy path, hardcoded everything else)692. User can handle rejection case (adds error value)703. User can see history (adds retrospective value)7172Each slice is deployable and testable. Each delivers incremental value.7374### SPIDR Decomposition7576Five techniques for splitting stories:7778| Technique | When to Use | Example |79|-----------|-------------|---------|80| **Spike** | Uncertainty blocks estimation | Extract time-boxed investigation; then build on the decision |81| **Paths** | Multiple workflow variations | Split "checkout" into: saved payment, new card, PayPal, failed+retry |82| **Interface** | Multiple channels/devices | Split "view dashboard" into: desktop, mobile, email summary |83| **Data** | Varying data scope | Split "export users" into: single user, filtered subset, all with progress |84| **Rules** | Varying business rule complexity | Split "calculate tax" into: single-state, exemptions, multi-jurisdiction |8586### Additional Slicing Patterns8788- **Workflow slicing**: Decompose by stages of a user journey (initiate, review, input, choose, transact, confirm). Each stage is independently valuable.89- **Data lifecycle slicing**: Decompose by CRUD operations. Start with READ (proves data exists), then CREATE, then UPDATE/DELETE.90- **Interface fidelity slicing**: Decompose by interaction richness (exact match, fuzzy match, filters, sorting, suggestions). Each layer adds richness.9192### Validation Order9394When multiple slices exist, order by:951. **Highest risk** -- validate assumptions that could invalidate everything962. **Highest learning** -- get feedback that informs remaining slices973. **Highest value** -- deliver what matters most if project is cut short9899Every slice must be independently deployable and deliver observable value. Test: can a user tell the difference before and after this slice ships?100101## Anti-Patterns: Form Addiction Symptoms102103When you see these, you're mimicking, not thinking:104105| Symptom | Diagnosis |106|---------|-----------|107| Story fits template but team asks "what does this mean?" | Card without Conversation |108| AC list technical steps, not user outcomes | Implementation leaking into specification |109| Story can only be done by one specialist | Sliced by skill, not by value |110| "As a developer, I want..." | Story serves system, not user |111| Story takes multiple sprints | Not a story -- it's an epic wearing a mask |112| Team debates story during implementation | Insufficient Conversation before commitment |113114### Detailed Anti-Pattern Catalog115116| Anti-Pattern | Symptom | Cure |117|-------------|---------|------|118| **Template Worship** | Follows template perfectly, team still asks "what does this actually mean?" | Ask "what observable behavior changes?" and rewrite with specificity |119| **Technical Story** | "As a developer..." or "As the system..." | Find the user value it enables, or track as technical debt separately |120| **Epic in Disguise** | Seems reasonable, takes multiple sprints, scope keeps growing | Decompose by specific, completable sub-outcomes |121| **Componentized Story** | Maps to technical layers (DB -> API -> UI), sequential dependencies | Slice thin vertically through all layers; each slice delivers complete value |122| **Orphan Card** | Card goes straight from backlog to sprint without refinement | Require refinement session: team estimates without wild variance, edge cases identified, AC agreed |123| **Implementation Leak** | AC describe HOW (calls POST /api/users, inserts row) not WHAT | Rewrite AC as observable outcomes: "user sees confirmation", "user appears in admin list" |124| **Moving Target** | Story changes during sprint, "one more thing" becomes three | Stories freeze once committed; new requirements become new stories for future sprints |125| **Checkbox AC** | AC test existence (button exists, button is blue) not function | AC should be user-verifiable: "user submits form and receives confirmation within 3 seconds" |126127## The Chef's Protocol1281291. **Start with outcome**: What can users do afterward that they couldn't do before?1302. **Find the smallest slice**: Identify the minimum that delivers that outcome1313. **Write AC as experiments**: Specify how to prove the outcome occurred1324. **Use template if helpful**: The format serves clarity, not compliance1335. **Invite conversation**: The card begins discussion, not documentation
ryzhakar