Backlog refinement (grooming): cadence, ownership, and what "ready" means

Backlog refinement — still widely called grooming — is the ongoing work of getting product backlog items ready before the sprint they’ll be built in: clarifying what each item means, splitting the ones that are too big, adding acceptance criteria, sizing them, and keeping them ordered by priority. It isn’t a single meeting so much as a habit. And it’s the quiet difference between sprint planning that’s calm and sprint planning that’s a two-hour argument.

Is it a ceremony or not?

Technically, no. The Scrum Guide doesn’t list backlog refinement as one of the events — it describes it as an ongoing activity that should consume no more than about 10% of the developers’ capacity. So the purists are right: it isn’t a ceremony.

And yet Asana’s guide to agile ceremonies is titled “4 events + backlog refinement,” and most working teams give refinement a standing session on the calendar and run it like any other ceremony. Both camps are pointing at the same truth from different sides: refinement is not a formal event, but treating it like one is usually the right call. Skip it and the cost doesn’t disappear — it just moves into sprint planning, where it’s more expensive and worse-timed.

What refinement actually does

Refinement takes raw backlog items — often a title and a vague hope — and makes them workable. In practice that’s four moves, running continuously:

• Clarify. Turn “improve onboarding” into something with a clear intent and acceptance criteria the team can test against.
• Split. Break items too big to finish in one sprint into thin, independently valuable slices. This is a craft of its own — see splitting user stories.
• Size. Reach a shared story-point estimate, usually via planning poker, so relative effort is understood before commitment.
• Order. Keep the backlog sorted so the most valuable, most ready work sits at the top where planning will reach for it.

The output isn’t a document. It’s a rolling buffer of items that are ready to be pulled — typically a sprint or two ahead of where the team is now.

Cadence: how often, how long

There’s no rule, but there is a sensible default: one short recurring session as the anchor, plus continuous small touches in between.

For a two-week sprint, most teams run a single refinement session mid-sprint, timeboxed to about an hour, and top it up ad hoc as questions come up. Weekly works just as well. What matters is less the exact slot than the buffer: you’re aiming to always have roughly a sprint’s worth of ready work queued, so planning never opens the backlog to find nothing it can commit to.

Two failure modes bracket the right amount. Too little, and planning becomes refinement-under-time-pressure — the team clarifies and splits on the clock, and commits to work it barely understands. Too much, and refinement swells into a second planning meeting, litigating detail on items that may never reach a sprint. Keep it inside the Scrum Guide’s ~10%-of-capacity guideline and it stays useful.

Who runs it

The product owner owns the backlog — priority, intent, and the why of each item are theirs. But refinement is a team sport. The developers are the ones who ask the awkward questions, surface the complexity nobody costed, and do the actual sizing. A product owner refining alone produces items that are crystal clear to exactly one person and full of surprises for everyone else the moment planning starts.

The scrum master keeps the session timeboxed and stops it drifting into design-by-committee. Beyond that, the fewer spectators the better.

What “ready” means: the Definition of Ready

The point of refinement is to make items ready — and “ready” deserves a definition, the same way “done” does. A lightweight Definition of Ready is the checklist an item must pass before the team will commit to it in planning: it’s understood, it’s small enough to finish in a sprint, it has acceptance criteria, dependencies are known, and it’s estimated.

Refinement and planning are a relay, not a rivalry — refinement gets items ready, planning commits to them. If the line between them feels blurry on your team, sprint planning vs backlog refinement draws it clearly. For where refinement sits relative to the formal events, see scrum events vs ceremonies.

Frequently asked questions

What is backlog refinement?

The ongoing activity of getting product backlog items ready to be worked on: clarifying what each item means, splitting the big ones, adding acceptance criteria, sizing them, and re-ordering by priority. It happens continuously through the sprint so that by the time an item reaches planning, the team can commit to it without a fight.

Is backlog refinement a Scrum ceremony?

No — the Scrum Guide doesn’t list it as an event. It’s an ongoing activity, not a fixed meeting, and the Scrum Guide says it should take no more than about 10% of the developers’ capacity. But most teams give it a recurring session and treat it like a ceremony, because skipping it is what turns sprint planning into chaos.

What is the difference between backlog grooming and backlog refinement?

None — they’re the same activity. “Grooming” is the original term; the Scrum community shifted to “refinement” because grooming picked up unfortunate connotations. Plenty of teams still say grooming. The work is identical either way.

How often should you refine the backlog?

Continuously, with one short recurring session as the anchor — commonly once a week, or once mid-sprint for a two-week cadence, timeboxed to roughly an hour. The goal is a rolling buffer of ready items, usually a sprint or two ahead, so planning always has good material to pull from.

Who runs backlog refinement?

The product owner owns the backlog and drives priority and intent, but refinement is a team activity — the developers ask the questions, surface the hidden complexity, and do the sizing. A product owner refining alone produces items that make sense to one person and surprise everyone else in planning.