User stories and acceptance criteria
In the last lesson you wrote requirements and business rules for moving phone orders into the Partner app. Now the agency's team needs work it can build in two-week sprints. This lesson shows you, as the business analyst, how to turn those requirements into a story map, thin stories and acceptance criteria built from real examples, and how to check a story is ready without turning that check into a wall.
By the end you can
- Turn requirements and business rules into stories that still trace back to them
- Build a story map of the reorder journey and cut a walking skeleton release
- Split a big story into thin vertical slices with the SPIDR patterns
- Write Given/When/Then criteria from key examples, including over limit, after cut-off, offline and case versus unit
- Use a definition of ready as a short conversation check, and keep it apart from the definition of done
The everyday picture
Your family plans a two-week trip. You could plan every day of the first city perfectly and leave the train tickets, the hotels and the money for later. Or you could first make sure a short, plain version of the whole trip works: tickets booked, one bed for every night, cash for the first day. Then you add the nice parts: the boat tour, the good restaurant, the day by the sea. If time or money runs out, the family still travels.
The same trip shows why examples matter. "Book a cheap hotel near the station" starts an argument later. "Under $60 a night, at most 10 minutes' walk from the station, with breakfast" ends it now. Story mapping is the first habit: make the whole journey work thinly before you make one part perfect. Acceptance criteria written from examples are the second habit: agree on concrete cases before anyone books anything.
From requirements to stories
In Requirements that work you wrote functional requirements, non-functional requirements and business rules with IDs. Stories sit on top of that work. A user story is a planning slice of it: small enough for Lagoon Digital to build and show in one sprint, and written from one user's side. The product course lesson User stories and acceptance criteria covers the story template, INVEST and the basic splits. Here you take the analyst's side: where a story's content comes from, and how it stays tied to the evidence.
Ron Jeffries' three Cs are a good way to see your job. The card is a few words: "Reorder last week's order". The conversation is where the details are agreed with the developer, the tester and the business. The confirmation is the acceptance criteria that prove it works. Many teams hold that conversation as three amigos: you, a Lagoon developer and a Lagoon tester. You bring what nobody else in the room has: the findings from Stakeholders and elicitation and the to-be process from Modelling processes.
Each story should point back to where it came from. Write the requirement and rule IDs on the card, for example "Traces to FR-03, RULE-02, RULE-05". Rules live once, in the rule catalogue, and stories refer to them. If finance later changes the credit rule, you change one rule and you can find every story it touches. That is traceability, and it is the base for change control in the next lesson.
Keep the evidence on the card too. Ravi says he reorders "mostly the same 30 things every week", and case versus unit mix-ups are the most common cause of the roughly 125 phone-order corrections a week. At about $9 each, that is about $1,125 a week, or roughly $58,500 a year. That one line tells the team why a reorder story must copy pack sizes exactly, and why a tester should try to break it.
Quick check
Finance changes the rule for one-off credit increases halfway through the project. What makes the impact quick to find?
One rule with an ID, referenced from stories, gives you a list of every story to check. Copying the rule into each story creates many versions that drift apart, and you still have to search them all. Memory fails as soon as people change teams.