A sprint planning meeting that runs long and ends in a vague commitment usually failed a week earlier, when nobody looked at the backlog. Backlog grooming, now more often called refinement, is the habit that prevents that, and it is where designers get their earliest say in what the team builds next. A backlog is only as useful as its top ten items are clear, and keeping them clear is continuous work rather than a meeting.
In this glossary topic:
What is backlog grooming?
Backlog grooming is the recurring activity of reviewing the product backlog so that the items near its top are clear, small enough to finish in a sprint, estimated, and ordered before they reach sprint planning. The backlog is the single ordered list of everything the team might build; grooming is the work that keeps that list usable. A groomed backlog has a top the team could start on tomorrow and a bottom that is allowed to stay rough.
The practice is now more often called backlog refinement. The Scrum Guide uses that word, and many teams followed, partly because "grooming" had picked up an unwelcome meaning in other contexts and partly because "refinement" describes the work better. The two names refer to the same activity, and the older one still appears in tools and job descriptions.
Refinement exists so that sprint planning can be a decision rather than a discovery session. By the time the team sits down to commit, the questions about what an item means, how big it is, and why it matters have already been asked and answered.
What happens in a refinement session?
A session works through the items nearest the top of the backlog, one at a time, and does some combination of five things. Clarifying: the product owner explains the intent and the team asks what is in and out of scope until the acceptance criteria describe a result everyone recognizes. Splitting: an item too large for a sprint is divided into smaller ones that each deliver something on their own, by user type, by step in the flow, or by simplest version first. Estimating: the team sizes the item, often in story points, and a size nobody can agree on is itself a signal that the item is not yet understood. Reprioritizing: new information from customers, data, or the last sprint moves items up or down. Removing: items nobody has asked about in months are closed, so the list stays honest.
The output is not a document but a changed backlog. Refinement has worked when the next sprint planning has nothing left to argue about, and a session that produced a long discussion and no change to any item has not done its job.
Who takes part, and how often?
The product owner leads, because ordering the backlog is their responsibility and they hold the context on why each item exists. Developers attend because they will estimate and build the work, and their questions are what expose hidden complexity; a product owner who refines alone and presents the result misses exactly that input. Designers attend for reasons covered below. Stakeholders join for a specific item they requested rather than as standing members, and a scrum master keeps the session on the items rather than on the roadmap.
The cadence is continuous. The Scrum Guide treats refinement as an ongoing activity rather than one of the sprint's formal events, so there is no required meeting and no fixed timebox. Most teams hold one scheduled session per sprint, often around its midpoint, and refine the rest of the time in passing: in a comment thread, or in a short conversation between the product owner and one developer. The session is the visible part of a habit that runs all sprint, and teams that refine only in the session tend to run out of ready work. The Terms in Agile Fundamentals lesson places refinement alongside the rest of the sprint vocabulary it depends on.
How does refinement differ from sprint planning and a retrospective?
The three meetings are easy to confuse because all of them look at the same backlog. Sprint planning happens at the start of a sprint and answers one question: what the team commits to deliver in the coming sprint, and how. It consumes refined items and should not have to produce them. A retrospective happens at the end of a sprint and looks at the team's process rather than its work: what went well, what did not, and what to change. It can change how refinement is done, but it does not refine anything.
Refinement sits between the two in time and in subject. Planning decides what to build next, the retrospective decides how to work next, and refinement makes sure there is something worth building when planning arrives. The sprint review, which shows finished work to stakeholders, is the fourth sibling, and the feedback it produces is one of the main inputs to the next refinement session.
What does backlog refinement look like in practice?
Picture a session that takes the top slice of the backlog, roughly the next two sprints' worth, and leaves each item in one of three states: ready, needs more work, or removed. A ready item has a clear statement of intent, acceptance criteria, an estimate, and no open dependency. The detail thins with distance: the items at the top are small and specific, the ones a quarter out are a title and a sentence. A backlog is refined from the top down, and the detail should fade with distance, because effort spent on items far from delivery is effort the team will likely spend again.
A backlog item in the form refinement aims for: a user story that names who wants it, what they want, and why, in one sentence. An item written this plainly can be questioned, split, and estimated; one that reads "balance alerts" cannot. From the lesson Agile Ceremonies.
What do designers contribute to refinement?
Consider an item that reads "redesign the onboarding flow" sitting near the top of a backlog. Developers cannot estimate it, because there is no design yet; the product owner cannot split it, because nobody knows what the pieces are. A designer in the room can say so, and the item becomes two: a design task for the next sprint and a build task to be refined once the design exists. Flagging the items that need design before they can be estimated is the designer's most useful contribution, and the one most often missing when designers are not invited.
Designers also bring research. A finding from last month's interviews can move an item up, split it, or kill it, and refinement is the moment when that evidence changes the plan rather than sitting in a report. They keep design debt visible by adding items for the inconsistencies and shortcuts that accumulate, so the debt competes for priority in the open. And they shape user stories toward outcomes rather than screens, which keeps the conversation on what the user is trying to do. What a well-formed backlog item carries before it is ready to build is covered in the Planning Roadmaps and Backlogs lesson.
Where does backlog refinement go wrong?
Three failure modes recur across agile teams. The first is refinement as reordering: the session moves items up and down, nobody asks what they mean, and sprint planning inherits the same vague cards in a new sequence. Ordering is the product owner's job between sessions; the session's job is to make the top items ready.
The second is refining too far ahead. Items polished for a sprint three months away go stale: the customer's situation changes, a dependency shifts, the estimate no longer holds, and the work has to be done again. Refinement should stay a sprint or two ahead of delivery, with everything further out left deliberately rough.
The third is the backlog as a wish list. When every request is added and nothing is removed, the list grows past the point where anyone can read it, and refinement turns into archaeology. Prioritization frameworks help decide what stays near the top, but the harder act is closing what will never be built, and a backlog nobody can read is not a plan.
