Backlog Refinement: How to Run It, and Why It Stopped Being Grooming

Backlog refinement is the ongoing work of making the top of the backlog ready: splitting items that are too big, clarifying what each one means, sizing it and putting it in order. Scrum used to call it grooming and renamed it in 2013. It is not one of Scrum’s events and has no fixed length, so most teams hold a regular session of about an hour, with the person who owns the order and the people who will do the work, and leave it with a handful of items that can be started without another conversation.

What the Scrum Guide says about refinement

The 2020 Scrum Guide↗ (opens in a new tab) describes Product Backlog refinement as “the act of breaking down and further defining Product Backlog items into smaller more precise items”. It calls it an ongoing activity that adds details such as a description, an order and a size, and it adds three points worth keeping in mind:

• Items that can be Done by the team within one Sprint are ready for selection at Sprint Planning, and they usually reach that state through refinement.
• The Developers who will do the work are responsible for sizing it. The Product Owner can help them understand trade-offs, but does not set the size.
• The Product Owner is accountable for ordering the Product Backlog and for making sure it is understood.

What the guide does not say matters as much. Refinement is not listed among the five events, it has no timebox, and there is no required format. Earlier versions were more specific: the 2017 Scrum Guide↗ (opens in a new tab) said refinement usually took no more than 10% of the Development Team’s capacity. The 2020 guide dropped that figure, so treat it as history rather than a rule.

Why it stopped being called grooming

The Scrum Guide’s own revision notes↗ (opens in a new tab) record both steps. The 2011 guide added “the practice of Product Backlog Grooming”. The 2013 guide changed it: “The Product Backlog is refined rather than groomed”, and in the same change named the result, items that are ready for Sprint Planning. The notes do not give a reason for the new word.

The Agile Alliance glossary↗ (opens in a new tab) does. It lists refinement as “formerly known as backlog grooming” and puts the shift down to the increasingly negative connotation of the word grooming, which had originally been meant as gardening imagery: trimming, pruning and cleaning. It also records other names for the same practice, such as backlog management and Story Time, and dates the earliest recorded mention of grooming to Mike Cohn in 2005. Plenty of teams still say grooming, and nobody will misunderstand you, but refinement is the term in the guide and the one to use in anything written down.

Inputs and outputs

A refinement session goes well when people arrive with the right material and leave with something concrete. Bring:

• The current order of the backlog, and the goal it is serving.
• The top 10 to 15 items, each with at least a title and the problem it solves.
• Anything new since last time: requests, bugs found in production, results from the last release.
• Open questions that were parked last session, with any answers that have come in.

Leave with:

• Enough ready items at the top for the next stretch of work, usually one to two Sprints’ worth, or the next week or two if you do not use Sprints.
• Every item that was too big split into smaller ones, each still worth doing on its own.
• Sizes on the ready items, given by the people who will do the work.
• Duplicates merged and dead items closed, with a reason.
• Each remaining question written against the item it blocks, with the name of whoever will answer it.

Some teams agree a Definition of Ready: a short list of things an item must have before it can be started. The Agile Alliance↗ (opens in a new tab) describes it as the counterpart to the Definition of Done, usually based on the INVEST criteria. Keep it to three or four lines, or it turns into a gate that stops work instead of a check that helps it.

Who attends

• The Product Owner, or whoever owns the order of the backlog. Without them, nobody can say what matters most, and the session turns into estimation.
• The people who will do the work. They ask the questions that expose hidden work, and they give the sizes.
• Occasionally, a specialist for one item: a designer, a security reviewer, the person who asked for the feature. Invite them for the ten minutes their item needs, not the hour.
• A facilitator is useful for larger teams. In Scrum that is often the Scrum Master, but it can be anyone who keeps time and keeps the discussion on the item in front of the group.

Keep it small. The whole team does not need to discuss every item; many teams send two or three people to prepare the next batch and bring the rest in when it is presented at planning.

How often, and for how long

Because the guide sets no timebox, this is a team decision. A common rhythm for a two-week Sprint is one session a week of 45 to 60 minutes, or one in the middle of each Sprint. Adjust by the result, not the calendar: if planning keeps stalling on unclear items, refine more often; if the top of the backlog is ready weeks in advance and keeps changing before anyone reaches it, refine less.

A one-hour agenda

1. 5 minutes: restate the goal and look at what changed since last time. New items go to the bottom unless someone argues otherwise.
2. 10 minutes: close what is dead. Duplicates, requests overtaken by events, bugs nobody can reproduce. Say why for each.
3. 30 minutes: work down from the top. For each item: what problem it solves, how anyone will know it is done, whether it fits in one Sprint or needs splitting, and a size from the people who will build it. Stop an item after five minutes and write down the question that is blocking it.
4. 10 minutes: reorder. The Product Owner moves items in the light of what was learned, out loud, so everyone hears the reasons.
5. 5 minutes: read back the open questions and who will answer each before next time.

Where an AI assistant helps

Most of the preparation is reading, which an assistant connected to your board does well: flagging duplicates, asking the question that would make an item ready, proposing splits and gathering evidence for sizing. Sprint planning with AI has a prompt for that and the rules for keeping the decisions with people. One pre-read that pairs well with it is a list of what has gone stale:

Read the To Do lane (lane "backlog").
List, without changing anything:
- tasks not updated in the last 90 days;
- tasks with an empty plan in the top 15 by priority;
- tasks sized xl, which need splitting before they can start;
- pairs that look like the same request, with both refs.
Comment on each with one line saying why it is listed.

That gives the session’s “close what is dead” step a list to work from. The assistant proposes; the room decides what closes.

Refinement without sprints

Refinement is not tied to Sprints. The Kanban Guide↗ (opens in a new tab) requires no particular meetings and says new work should be started only when there is a clear signal of capacity, which makes refinement a question of keeping the queue healthy rather than filling a Sprint. Two approaches work:

• Refine on a trigger. When the “ready” part of the queue falls below a set number of items, say five, the next person to notice books a short session.
• Refine on a light cadence. A fixed 30 minutes a week keeps the top of the list ready without anyone watching a number.

Either way the output is the same: the next items anyone will pull are clear, small and in order. The differences between the two methods are covered in Kanban vs Scrum.

Refining on a fenbs board

fenbs has no sprints, story points or refinement screen, and needs none of them for this. The To Do lane is the backlog and Next Up is what the team has committed to next, so refinement is the work of getting tasks ready to move from one to the other.

• Each task has a note for the problem and a plan for how it will be done. A task with an empty plan near the top of To Do is the clearest sign it is not ready.
• Size is optional and runs XS to XL. XL means split it: file the smaller tasks and link them to the original under Related tasks.
• Priority runs 1 to 10, with 1 the most urgent. The exact order within To Do is a drag; on a team board the Shared order is the one everybody sees.
• Closing is explicit. Move a dead task to Completed and choose how it ended: Won’t fix, Duplicate, Cannot reproduce or Obsolete, so it never counts as delivered.
• Arguments that get settled go on the Decisions page, with who decided and why. Deciders are always people; an assistant can write a decision down but is never the one who made it.
• Moving tasks between lanes is its own permission, so an assistant connected with read and comment access can prepare the whole session without being able to change the order.