Why this matters: the Story is the unit that gets estimated, tested and marked done. If the Story is bad, the estimate is fiction, the test cases are impossible and “done” is a negotiation. Where Stories sit in the hierarchy is in Work Breakdown Hierarchy.
The Story is a promise for a conversation
The most useful thing I ever read about User Stories is Ron Jeffries’ idea of the three Cs: the Card (the short sentence), the Conversation (the discussion it triggers), and the Confirmation (the acceptance criteria you agree on). The written sentence is not a specification document. It is a reminder to have the conversation, and the conversation’s output is written down as Acceptance Criteria.
This is why “we wrote the Story so we are ready to code” is wrong. The Story sentence alone is one third of the work.
The template, and when to ignore it
As a <who>
I want <what capability>
So that <what benefit>
The “so that” is the part everyone drops, and it is the most valuable part, because it is the only place the purpose is recorded. Purpose is what lets a developer make a sensible decision at 6pm when they hit a case nobody discussed, and it is what lets a Product Owner cut scope intelligently later.
Compare these:
As a user, I want to export invoices as PDF.
As an accountant, I want to export an invoice as PDF so that I can email a copy to a client who cannot access the portal.
The second one tells you the PDF must look presentable, must contain the client facing fields, and probably needs the company logo. None of that is obvious from the first.
Ignore the template when it makes the sentence worse. For technical enabler work, write a plain sentence with a real reason. “Move report queries to a read replica so that heavy reports stop slowing down invoice entry” is a fine Story. “As a developer I want clean code” is not a Story, it is a wish.
INVEST: the quality checklist
The Agile Alliance definition of a good Story, and the fastest way to catch a bad one during refinement:
| Letter | Means | The question to ask out loud |
|---|---|---|
| I | Independent | Can we build this without three other Stories finishing first? |
| N | Negotiable | Is there room for developers to choose the solution, or have we written a design document? |
| V | Valuable | Does finishing this alone produce something worth having? |
| E | Estimable | Do we understand it well enough to size it? If not, we need a spike. |
| S | Small | Can it comfortably finish inside one sprint, with testing? |
| T | Testable | Can somebody objectively prove it works? |
Two of these deserve extra attention because they are the ones that bite.
Small is the one that decides your sprint predictability. The Scrum Guide says items selected for a sprint should be capable of being Done within that sprint. If your Stories keep ending the sprint at 70% or 90%, the honest conclusion is not “we need to work faster”, it is “our Stories are too big or too poorly understood”. Rule of thumb I like: no Story should be more than about a quarter of the team’s sprint capacity. If one Story can sink the sprint on its own, it is too big.
Testable is the one that decides whether you will have test cases. If nobody can describe how they would prove it works, the Story is still an idea. Send it back to refinement. The link from Story to test case is spelled out in Test Case Strategy.
Splitting: the actual skill
Most teams know Stories should be small. Very few know how to make them small, so they give up and let a 21 point monster into the sprint. Splitting is a learnable technique with a handful of patterns. Mike Cohn’s SPIDR is the easiest set to remember, and I have added the ones I use most.
Take one over sized Story as the running example:
As a store manager, I want to manage stock so that I always know what I have.
That is not a Story, that is a Feature. Here is how each pattern cuts it.
By workflow step. Find the sequence of steps a user goes through and ship them one at a time. Receive stock, then issue stock, then transfer stock, then adjust stock. The first slice alone is useful.
By business rule. Ship the main rule first, add the special rules as separate Stories. “Decrease stock on sale” first. Then “block a sale that would take stock below zero”. Then “allow negative stock for back ordered items with a warning”. Each rule is a separate testable behaviour, and each one has its own edge cases.
By happy path versus error handling. Ship the successful flow, then the failure flows. This one feels dangerous but is fine as long as the error Stories are genuinely in the same sprint or the next, and as long as the Story is not customer visible until both are done. Never let “handle the failure case” become a permanent backlog resident, because that is exactly how you end up with a product that works in demos and falls over with real users.
By data type or parameter. Support one unit of measure first, then multiple. One location first, then multi location. One currency, then many. This is one of the highest value splits because the multi variant version is usually five times the work of the single one, and often is not needed immediately.
By interface or channel. Web first, then mobile. Manual entry first, then bulk import, then API. Same capability, very different effort.
By operation (CRUD). Create first, then view, then edit, then delete. Almost nobody needs all four in the first sprint, and delete in particular usually carries hidden work like referential checks and audit trails.
By performance or scale. Make it work correctly first, then make it work for 50,000 rows. “Handles 500 items” and “handles 500,000 items with pagination and indexing” are genuinely different Stories with different risk.
Remove the spike. If a Story is only large because of unknowns, pull the unknown out into a timeboxed investigation and re estimate afterwards. Do not carry uncertainty inside a Story and pretend it is size.
Split manage stock using these and you get something like: receive stock into one location, issue stock on an invoiced sale, block a sale below zero stock, see current quantity for one item, transfer stock between two locations, import opening stock from a spreadsheet. Six Stories, each testable, each shippable, and now you can actually choose which ones matter this month.
What is not a valid split: cutting by technical layer. “Build the stock table”, “build the stock API”, “build the stock screen” are three Stories that each deliver nothing and can only be tested together. Always slice vertically, thin but complete.
How to know a Story is too big without arguing
Any one of these is enough to send it back:
- It has the word “and” in it, or a comma joining two capabilities.
- It has more than roughly seven or eight acceptance criteria.
- Two people describe its scope differently when asked separately.
- It scores 13 or more in Estimation and Story Points.
- It has carried over from one sprint already.
- Nobody can say what it means to test it.
Get three heads on it, not one
The pattern usually called Three Amigos: before a Story is called ready, at least one person from each of product, development and testing looks at it together. Fifteen minutes, not a meeting marathon.
The reason is that each role sees a different set of missing cases. Product knows the business exception. The developer knows the system constraint. The tester knows the edge case that broke a similar feature last year. Any one of them alone writes an incomplete Story, and the missing pieces show up later as “feedback” that overflows the sprint. Finding them at refinement is dramatically cheaper than finding them at demo, which is the entire argument of Sprint Planning and Refinement.
A very cheap way to run this is Example Mapping (Matt Wynne). Take one Story, and on a whiteboard collect: the rules it must obey, one concrete example per rule, and the open questions. In twenty five minutes you either have a well understood Story with its acceptance criteria already half written, or you have discovered that it is really three Stories and a question for the stakeholder. Both outcomes are wins. The examples you collect become your Acceptance Criteria almost word for word.
Anti patterns I keep seeing
The design document disguised as a Story. “As a user I want a dropdown at the top right calling GET /api/v2/items with a debounce of 300ms.” You have removed the N from INVEST and taken responsibility for a design decision you are not making. Say the outcome, let developers choose the mechanism.
The invisible user. “As a user, I want to use the system.” Which user? An accountant, an admin and an auditor want completely different things, and naming the role usually exposes that you were building for the wrong one.
The Story with no benefit. If nobody can complete “so that”, ask why it is in the backlog at all. Sometimes the honest answer is “a big customer asked for it”, which is a perfectly good reason, but write that down, because it tells you what happens if that customer leaves.
The eternal Story. The Story that has been in progress for three sprints, growing as it goes. This is not a Story problem, it is a scope problem, and the fix is in Feedback and Scope Control.
The Story that is really a task. “Add index on invoice_date.” No user outcome, no benefit, no test case. That is a Task under some Story, or a chore. Not everything needs to be a Story.
A finished example
Here is what a Story looks like when it has actually been refined. The structure is repeated in Templates so you can copy it.
Story: As an accountant, I want to be warned before an invoice takes an item’s stock below zero, so that I do not promise stock we do not physically have.
Acceptance criteria
Given an item with 5 units in stock, when I invoice 6 units, then a warning is shown before saving and the invoice cannot be saved.
Given the same item, when I invoice exactly 5 units, then the invoice saves normally with no warning.
Given an item marked “allow negative stock”, when I invoice more than available, then a warning is shown but saving is allowed and the stock goes negative.
Given a multi line invoice where only one line breaches stock, then the warning names the specific item and line.
The check uses stock at the invoice date, not today’s stock.
A draft invoice does not affect stock and does not trigger the warning.
Out of scope: back order creation, purchase order suggestions, reservation of stock for quotes. Those are separate backlog items.
Notes: criterion 5 is the subtle one. Backdated invoices are common at month end.
Look at the “out of scope” line. That single line is one of the highest value habits in this whole set of notes, because it converts the demo conversation from “you forgot back orders” into “yes, that is the next Story, it is already in the backlog”. It turns an argument into a plan.
Six acceptance criteria means at least six test cases, and they were written before a line of code existed. That is how a feature ends up with proper coverage without a separate testing project, which is the argument made in full in Test Case Strategy, and it is how the Story passes Definition of Ready instead of entering the sprint as a rumour.