Backlog Refinement: How to Run the Meeting (2026 Guide)
Run backlog refinement that pays off: ideal cadence and duration, a proven agenda, definition of ready, splitting and estimation techniques, common mistakes.
By the RoadmapHero team · Updated on · 6 min read
Key takeaways
- Backlog refinement is the recurring activity where the team clarifies, splits, estimates and challenges upcoming items so the top of the backlog is ready to be planned.
- For two-week sprints, hold a weekly 45–60 minute session mid-sprint with the PM and developers, covering 5 to 8 prepared items at about 10 minutes each.
- An item is ready when its user value is stated, acceptance criteria are testable, it is estimated, dependencies are identified and it fits within one sprint.
- Refine only about 1.5 to 2 sprints of work ahead, and keep refinement under roughly 10% of team capacity, as the Scrum Guide suggests.
Backlog refinement (formerly "grooming") is the recurring activity where the team prepares upcoming backlog items: clarifying them, splitting them, estimating them, and deciding what "ready" means. Done well, it is invisible — sprints just start smoothly. Done badly or not at all, every downstream ceremony pays the price: planning drags, estimates are guesses, mid-sprint surprises multiply. This guide covers the purpose, the ideal cadence, a proven agenda, and the mistakes that turn refinement into a time sink.
What backlog refinement is for
Refinement has exactly one output: a top of backlog that is ready to be planned. Concretely, the session exists to:
Clarify: everyone understands what the item is, for whom, and why it matters.
Split: items too big for a sprint become 2–4 smaller ones that each deliver value.
Estimate: the team sizes items — and estimation questions surface hidden complexity.
Challenge: some items die here. A refinement that never deletes anything is a rubber stamp.
Order: fresh information feeds back into priority — though the actual ranking decision remains the PM's job, done with a method like the ones in our guide to backlog prioritization.
What refinement is not: a re-planning of the current sprint, a roadmap debate, or a solution-design workshop. Those conversations matter, but they have other homes.
Cadence, duration and who attends
The Scrum Guide suggests refinement should consume no more than ~10% of the team's capacity. In practice, for a team on two-week sprints:
Parameter | Recommendation | Why |
|---|---|---|
Cadence | Weekly | Questions incubate between sessions; the backlog never rots |
Duration | 45–60 minutes | Beyond an hour, attention and decision quality collapse |
Attendees | PM/PO + developers (whole team or rotating subset of 3–4) | The people who will build it must shape it |
Timing | Mid-sprint, never the day before planning | Leaves time to answer open questions before planning |
Items per session | 5–8, prepared in advance by the PM | Ten minutes per item forces focus |
The PM's preparation is decisive: items arrive with a draft description, user value, and open questions listed. The session refines drafts — it does not write from a blank page.
A proven refinement agenda (60 minutes)
0:00–0:05 — Context. What changed since last week: new insights, incidents, feedback, priority shifts.
0:05–0:15 — Follow-ups. Answers to questions parked last session; items that were blocked get unblocked or descoped.
0:15–0:50 — Item by item. For each candidate: the PM presents the problem and value (2 min), the team asks questions and challenges (4 min), then split if too big, write or fix acceptance criteria, and estimate (4 min). If an item exceeds its 10 minutes, park it with a named owner for the open question.
0:50–1:00 — Wrap-up. Which items are now ready, which need homework, and does the ready pool cover the next 1.5–2 sprints?
The 10-minute-per-item timebox is the single most effective facilitation rule. An item that cannot be understood in 10 minutes is not refinable yet — it needs discovery work, not more meeting time.
Definition of ready
The definition of ready (DoR) is the exit gate of refinement and the entry gate of sprint planning. A workable DoR fits on one hand:
The user problem and expected value are stated in one or two sentences.
Acceptance criteria are written and testable.
The team has estimated the item.
Dependencies (teams, APIs, design, data) are identified and not blocking.
The item fits comfortably in one sprint (if not, split it).
Keep the DoR a guideline, not a bureaucracy: it exists to catch half-baked items, not to require a 15-field form before anyone can code. If your DoR regularly blocks obviously fine items, shrink it.
Techniques: splitting, estimation, 3 amigos
Splitting
Split by value slice, not by technical layer. Good axes: by workflow step (import → validate → publish), by user segment (admins first), by business rule (simple case first, edge cases later), by quality level (manual fallback first, automation next). A "backend story" plus a "frontend story" is not a split — neither delivers anything alone. For the bigger picture of how items nest, see epics vs user stories vs tasks.
Estimation
Refinement is where estimation belongs — never planning. Planning poker or async "estimate then discuss outliers" both work; the point is not the number, it is the conversation triggered by disagreement. A 3-vs-13 split on story points means two people imagine two different features. Resolve that now, not mid-sprint.
3 amigos
For complex items, run a short 3 amigos (product + dev + QA/design) before the group session. Three perspectives — value, feasibility, testability — catch most gaps in 15 minutes, and the item arrives at refinement already solid.
6 refinement mistakes to avoid
Refinement becomes re-planning. The session gets hijacked to reshuffle the current sprint. Current-sprint issues belong in the daily; refinement looks forward.
Refining the infinite backlog. Grooming items ranked #60 is pure waste. Refine 1.5–2 sprints deep, archive the graveyard below — a 300-item backlog is a storage problem, not a planning asset.
The PM monologue. If the PM talks 80% of the time, you have a briefing, not a refinement. The value is in the team's questions.
Design by committee. Eight people debating an API contract for 40 minutes. Park it: two engineers take it offline and report next week.
No deletion. If nothing ever gets rejected or closed in refinement, you are not challenging items — the backlog only grows.
Skipping it when busy. The busier the sprint, the more tempting to cancel refinement — and the more expensive the next planning becomes. It is the meeting that pays for all the others.
Refinement with RoadmapHero
RoadmapHero makes refinement shorter by making preparation cheap. The backlog is ranked by HeroScore, so the session naturally works top-down on what matters; each ticket carries description, acceptance criteria via custom fields, story points, dependencies and estimated costs — the definition of ready is visible at a glance. Items born from user requests keep their Customer Voice context attached, so "why does this matter?" is answered with real feedback instead of memory. The Ask assistant helps draft and split stories during preparation, and epics/stories keep splits organized. If delivery happens in Jira or Linear, two-way sync means refining in RoadmapHero updates the dev tool automatically. Free trial, transparent pricing in euros, no commitment.
Frequently asked questions
How often should backlog refinement happen?
Once a week for about an hour works for most teams on two-week sprints. It beats one long pre-planning session: shorter, more frequent touchpoints keep the backlog continuously ready and let questions incubate between sessions.
Who should attend backlog refinement?
The PM or product owner plus the developers who will build the items — either the whole team or a rotating subset of 3–4 people. Invite design or QA when items need their expertise. Stakeholders send input beforehand, they do not attend.
What is a definition of ready?
A short checklist an item must pass before entering a sprint: clear user value, acceptance criteria written, estimated, dependencies identified, small enough to finish within a sprint. It protects sprint planning from half-baked items.
How much of the backlog should be refined?
Only the top: roughly 1.5 to 2 sprints of ready work. Refining deeper is waste — priorities will change before those items are built, and the details you wrote will be stale.
Is backlog refinement an official Scrum event?
No. The Scrum Guide describes refinement as an ongoing activity, not a timeboxed ceremony. Most teams still schedule it as a recurring meeting because unscheduled refinement rarely happens.