“Backlog grooming” or “backlog refinement” is the meeting most teams half-skip — there’s no Scrum Guide ceremony for it, the value is hard to feel in the moment, and a poorly-run one feels like 90 minutes of arguing about ticket descriptions. This post is the runbook: what refinement is actually for, the 30-minute version that works, the two anti-patterns that ruin it, and what should never happen in a refinement meeting.
What backlog refinement is actually for
Three concrete outputs. If your refinement doesn’t produce these, you’re doing the wrong meeting.
1. Tickets near the top of the backlog have descriptions a future you (or a teammate) can pick up cold.
The acceptance criteria is in the ticket. The shape of the work is in the ticket. The “why” is in the ticket — even if it’s one sentence. Without this, sprint planning becomes “what does this ticket mean again?”
2. Tickets are roughly sized.
Not every ticket has story points yet. But the tickets you’d plausibly take into the next 1-2 sprints should have a number, even an approximate one. Without sizes, sprint planning becomes a sizing meeting, which makes the planning meeting take 90 minutes.
3. Stories that are too big are split.
A 13+ story spotted in refinement is much cheaper to split than the same story spotted in planning. In planning, you have to split it under time pressure with the whole team waiting. In refinement, you can think about it.
That’s it. Three outputs. Description quality, sizing, splitting.
The 30-minute version
For a team of 4-7 engineers running 2-week sprints, this is the schedule. Mid-sprint, weekly cadence (i.e., on the off-week of planning, run it once; on the planning week, skip).
00:00 - 00:03 | Quick context — what's in the next sprint shape?
00:03 - 00:18 | Walk top 5-8 backlog items
• Lead reads ticket title + acceptance criteria
• Anyone on team flags missing detail or risk
• Estimate (or "needs spike")
• Move to next
00:18 - 00:25 | Splits and spikes
• For each story flagged 13+ or "unclear"
• Either propose a split now or create a 1-pt spike
00:25 - 00:30 | Backlog tidy
• Bump priority of recently-blocked items
• Mark dead tickets as cancelled (don't quietly carry them)
Total: 30 minutes. Recurring weekly. One person facilitates (the lead, usually). Rotate over time.
The most important rule: refinement is not implementation design
This is the rule most teams break, and the reason most refinements run 90 minutes.
In refinement, the right question for each ticket is: “Do we understand what ‘done’ looks like, and is this small enough?”
The wrong question is: “How will we technically build this?”
The “how” conversation belongs in the implementation, after planning, when the engineer who picks the ticket is alone with the codebase. A 6-person team standing around debating “should we use a polling approach or push a webhook” for 20 minutes is wasting 2 hours of engineering time per sprint, on a decision that should be made by whoever picks up the ticket.
The cheap heuristic: if the conversation moves into a specific class name, library choice, or “I think we should use X pattern,” stop and tag it for follow-up. Refinement isn’t the place. Move on.
Anti-pattern 1: the silent backlog dump
Symptom: The lead has been adding tickets all week. Refinement is the first time the team sees them. Engineers stare at unfamiliar tickets while the lead reads each one, says “any questions?”, and the team — having no context — says “no.”
Result: tickets get rubber-stamped without scrutiny. Two weeks later in planning, half of them turn out to be ambiguous, oversized, or wrong.
Fix: tickets get added to the backlog throughout the sprint, with the team lead writing a one-line description and acceptance criteria when they create the ticket. Everyone has access to the backlog and can scan during the week. Refinement is a check, not a first-pass review.
If your team genuinely doesn’t have time for async backlog awareness, you don’t have a refinement problem — you have a backlog ownership problem. The lead is doing the team’s thinking instead of distributing it.
Anti-pattern 2: the open-ended discussion
Symptom: A ticket spawns a 20-minute discussion. Three people have different opinions. The facilitator lets it run because “it’s important to align.”
Result: refinement runs over, the team gets fatigued, and the next 4 tickets get rubber-stamped because nobody has energy.
Fix: 5-minute hard cap per ticket. If a ticket needs more than 5 minutes of discussion in refinement, it’s not refined — it’s blocked, and the right answer is one of:
- “This needs a spike. Create a 1-pt ticket: ‘investigate X, propose approach.’”
- “This is too big. Split it: I’ll come back next refinement with sub-tickets.”
- “This needs the customer/PM to clarify. Tagging them, will revisit.”
These are all legitimate refinement outputs. “We argued about it for 20 minutes” is not.
What should NEVER happen in refinement
A short list, learned the hard way:
- Live ticket-writing. If a ticket is so unclear it needs to be rewritten in the meeting, the meeting stops on it; lead takes ownership; revisit next week.
- Estimating tickets nobody on the team will work on. If it’s a frontend ticket and only one engineer does frontend, don’t make 5 people estimate it. Ask the frontend engineer privately; capture; move on.
- Re-litigating tickets the team already estimated. Once a number is on, it stays unless something material changes (scope, dependency, requirement).
- Adding tickets during refinement. New tickets go into the backlog. They’re refined next week, not now.
- Talking about tickets that are 5+ sprints away. Refine the next 2 sprints’ worth. Anything further is wasted effort because priorities will shift.
What about kanban teams?
Kanban teams have no sprint ceremony, but the same need exists: tickets near the top of the backlog need to be ready to pull. The format becomes a 15-minute weekly “ready check” — same outputs (descriptions, sizing, splitting) but smaller volume because you’re only looking at what’s near the WIP boundary.
If you’re scrumban, run the 30-minute scrum format.
What about teams with a Product Owner?
The PO writes ticket descriptions and decides priority. The engineering team estimates and flags splits. The meeting is the PO and engineers in the same room. The PO doesn’t estimate.
A common failure mode: the PO writes a 3-line description, the team estimates it, and only later realises the description was missing crucial context. The fix is the team asking “what does done look like for the user?” for every ticket, not just “is the description complete?” — descriptions can look complete and still miss the actual user expectation.
The cost of doing this badly
A team that skips refinement entirely loses ~2 hours per sprint to “what does this mean?” conversations during planning, plus mid-sprint discoveries that the work was bigger than estimated. For a 6-person team, that’s ~£3,000 per sprint of wasted engineering time. (See: Sprint Cost Calculator for your team’s number.)
A 30-minute weekly refinement costs the team ~£1,000 per sprint at typical UK engineering costs. The math is straightforward.
What this looks like in SprintFlint
SprintFlint shows the backlog with story points, sizing badges, and a “needs refinement” tag automatically applied to anything in the next 2 sprints without a description or estimate. The refinement meeting becomes “look at this filter, walk down the list” — no ticket falls through.
For teams that won’t switch tools, the cheap version: a Linear/Jira filter for priority > 0 AND points = empty AND sprint = next-two, run weekly.
TL;DR
- Refinement produces three things: ticket descriptions, sizes, splits. Nothing else.
- 30 minutes, weekly, one facilitator. Skip on planning weeks.
- The right question per ticket: “do we know what ‘done’ looks like?” Not “how will we build it?”
- 5-minute hard cap per ticket. Bigger conversations spawn a spike, a split, or a clarification request.
- Don’t refine tickets nobody on the team will work on. Don’t write tickets in the meeting. Don’t talk about 5-sprint-out work.
- A team that skips refinement loses ~2 hours per sprint to confusion in planning. The 30-minute meeting prevents this.