Home → Part 03
Grooming: Not a Ticket Reading Session
The PO reads the item, the team nods, everyone checks their phone. That is not a handover, it is an anaesthetic. This session should be a launch.
- The PO's job is the "why", not the "what". A team without context cannot own the work; it can only complete tasks.
- Show what is coming. Not just the next sprint but two or three ahead — that is the only way architectural pre-thinking can happen.
- Detail decreases with distance. Near sprint at pixel level, distant sprints at headline level.
- No solution design here. "How will we build it" belongs to technical analysis.
Refinement and grooming are not the same thing (in this series)
The Scrum Guide counts them as one event, and that is a defensible choice. In practice, though, two different jobs are being done — and when they are mixed, both are done badly:
| Refinement | Grooming | |
|---|---|---|
| Purpose | Filter and prioritise | Transfer context to the team |
| Who speaks | Product and business | Product Owner |
| Who listens | — | Developers + QA |
| Output | A filtered, scored list | Items the team understands and owns |
The practical benefit of the split: if refinement runs long, engineers lose nothing. If grooming runs long, that is a warning — the filtering stage did not do its job.
Purpose: loading context
By this point the PO has already filtered the ideas and turned them into clear requirements. The job now is to transfer that context. The critical difference:
The distinction looks small and the consequences are not. A developer who knows the context notices the overlooked corner of a requirement and asks about it. A developer without context does exactly what is written, and delivers the wrong thing flawlessly.
A concrete example
"We are adding a filter to the orders screen. Date range and status will be selectable."
"The call centre team spends about 40 minutes a day searching for orders. 80% of what they look for is pending orders from the last seven days. This filter is meant to cut that time in half."
With the second version the team asks: "so should the default filter be last 7 days plus pending?" That question is never asked with the first version — and it comes back after delivery as "what we actually wanted was...".
Beyond the next sprint
Grooming is not only about tomorrow's tasks. It is the PO's chance to show the roadmap. Three benefits:
- Pre-thinking. A developer who knows what is coming in two sprints shapes today's design accordingly. They will do this even if you do not ask — the brain works in the background.
- Motivation. The team sees that its work serves a bigger picture. A team with no visible roadmap feels like a queue consumer.
- Early objection. "If we are building that later, let us not model this table that way" is expensive two sprints from now and free today.
- Next sprint: acceptance criteria, screen drafts, edge cases — pixel level.
- +2 sprints: main flow and business rules, no screens.
- +3 and beyond: a one-line headline. Just "this is coming".
How the session runs
- Story. The PO explains the user story, the business need and the acceptance criteria.
- Context. Why now, for whom, which number is it meant to move?
- Questions. The team asks clarifying questions: "what if the user hits back?", "how does this look on mobile?", "what does an unauthorised user see?"
- Decision. Is the item ready, or does it go back to the PO?
If the PO cannot answer a functional question, the item is not ready. Pulling it into the sprint with "we will figure that out later" moves the ambiguity to the most expensive place: development. The team does not accept ambiguity; the item goes back.
My own addition: next to every question that cannot be answered in the session, write who will answer it and by when. Without those two pieces, a note saying "the PO will look into it" ends with the same question being asked again in sprint planning. It is the same rule as the retrospective action rule.
Anti-patterns
- Ticket reading: the PO reads the screen aloud, nobody speaks.
- Solution drift: the session turns into "which table should we write to".
- One-way traffic: no questions. A grooming with no questions was not understood.
- Passing unready items: "we will clarify the detail during the sprint."
- Require a "whose problem does this solve" sentence for every item
- Stop solution discussion and park it for technical analysis
- Wait for questions after each item — do not read silence as agreement
- Send unready items back, and treat that as a success
Checklist
- Does every item have written acceptance criteria?
- Did the team ask at least one question per item?
- Do unanswered questions have an owner and a date?
- Were the next two or three sprints shown in outline?
- Was the "how will we build it" discussion parked for technical analysis?
- Were unready items sent back?
Conclusion
Grooming is where business language is translated into product requirements. Done well, the session ends with this sentence: "Right, we understand what you need. Now let us work out how to build it."
If that sentence is never spoken, either the context was not transferred or the team has stopped asking. Both lead to the same place: questions asked mid-sprint.
The context handover, decreasing granularity and the golden rule are adapted from İbrahim Demir's Grooming post. The refinement/grooming comparison table, the with/without context example and the "owner + date for every open question" rule are my additions. Mike Cohn's User Stories Applied is the base reference here.