task-ops
Most teams do not have a backlog problem. They have a top of the backlog problem. The list is long, the bottom is full of things written eighteen months ago by someone who has left, and none of that hurts. What hurts is planning day arriving with the next five items still described in one line each, so the session turns into a discovery workshop and the plan that comes out of it is a guess.
Backlog grooming is the habit that prevents that specific failure. It goes by refinement now in most places, and the rename matters less than the scope. The work is not tidying the list. It is making sure the handful of items that will be picked up next are understood well enough that picking them up is uneventful.
The vocabulary here has drifted enough that it is worth going back to the source. Refinement appears in the 2020 Scrum Guide under the Product Backlog, not under the events:
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Source: scrumguides.org
Three things in that sentence do real work. Refinement is an activity, not a ceremony, which means there is no prescribed meeting, no prescribed length, and no rule that everyone has to attend. Teams that treat it as a mandatory weekly hour are adding something the framework never asked for, and teams that skip it entirely are dropping something the framework assumes is happening continuously.
The second is the word ongoing. An hour on Thursday is a way to make the activity visible, not a substitute for it. Most of the useful refinement in a healthy team happens in ten minute conversations between two people who then write down what they concluded.
The third is sizing. The guide is specific about who does it: the developers who will be doing the work are responsible for the sizing, and the product owner may influence them by helping them understand trade offs. That single line resolves most arguments about estimation authority. The person who will do the work sizes the work.
The guide also states the bar for an item to be eligible at all. Items that can be finished by the team within one sprint are deemed ready for selection in planning, and they usually reach that state after refining activities. So refinement has a definition of done of its own: split until it fits in a sprint, and the fitting is the point, not the precision of the number.
The most expensive mistake in this area is applying the same standard to the whole list. A backlog with two hundred items, each written to the same level of detail, represents weeks of analysis spent on things that will mostly be deleted or overtaken.
A better model is a gradient. The top few items are described well enough to start tomorrow: what the change is, who it is for, what counts as finished, what was explicitly excluded, and which open question would stop work if the answer came back wrong. The next tier is one paragraph and a rough size. Everything below that is a title and enough context that the person who wrote it could reconstruct the thought.
How deep the ready tier needs to be is a function of one number: how much work the team starts between refinement sessions. A team that refines weekly and starts roughly a week of work needs somewhere between one and two weeks of ready items at the top. More than that is inventory, and inventory in a backlog goes stale the same way it does anywhere else. Requirements change, the product changes, and a beautifully specified item from six weeks ago has to be re read and re checked anyway.
The practical test for readiness is not a checklist with nine boxes. It is a question: could one person pick this up, work on it for a day, and not need to interrupt anyone. If the answer is no, the item is not ready, and the specific reason it is not ready is the thing to write down. That reason is usually one of three: a decision nobody has made, a dependency on someone outside the team, or an item that is really three items wearing one title. Naming which of the three applies turns a vague blocker into a next action.
The honest answer is fewer people than usually attend. Refinement needs whoever can answer questions about intent, whoever will do the work, and nobody else. For a small team that is often three people for twenty minutes, not seven people for ninety.
The failure pattern is the whole team sitting through a detailed discussion of one item that two of them will work on. Attention drains, the session gets a reputation as the meeting where nothing happens, and attendance becomes a compliance exercise. Splitting into pairs, each taking two or three items, and then spending ten minutes together on anything that turned out to be contentious keeps the cost proportional.
Two roles earn their place even when they are not doing the work. Somebody has to be able to say no to scope, on the spot, without going away to ask. And somebody has to write the outcome down while the conversation is happening, because a refinement conversation that is not recorded has to happen again.
There is no correct frequency, but there are predictable consequences to each choice.
| Cadence | Works when | What goes wrong |
|---|---|---|
| Continuous, in pairs, as needed | The team is small and sits close, or writes well | Nothing gets sized consistently, and the top of the list quietly empties |
| Once a week, short, few attendees | Most small teams shipping steadily | Drifts into status reporting unless someone guards the agenda |
| Once per sprint, before planning | Longer cycles, external stakeholders | Planning inherits everything that was too hard to decide |
| Only when planning stalls | Never, in practice | Planning becomes the refinement session, and runs long |
The last row deserves naming because it is the default state of most teams that believe they have no grooming problem. The Scrum Guide allows planning up to eight hours for a one month sprint, and a session that consistently uses that budget is usually doing refinement under a different name. Planning is meant to answer why this sprint is valuable, what can be finished, and how, with the developers decomposing selected items into work of a day or less. None of those three questions can be answered while the team is still arguing about what an item means.
Backlogs grow because adding to them is free. The cure is a rule applied without ceremony rather than a periodic purge that everyone dreads.
A simple version: anything untouched for a set period gets closed with a note saying it was closed for age and can be reopened. This is not information loss. An item nobody has thought about in six months either does not matter or will come back, and when it comes back it will arrive with fresh context, which is better than the stale version. Teams that resist this are usually protecting the feelings of whoever filed the item, which is a real concern and is better handled by saying so out loud than by keeping a list nobody reads.
The other half of the policy is the entry gate. A one line item with no owner and no context costs almost nothing to file and a surprising amount to refine later, because reconstructing intent takes longer than stating it did. Requiring one sentence of why at the moment of filing removes most of the archaeology. It also has a filtering effect, since a fair number of items never get written once the person filing them has to articulate what problem they solve.
Estimating everything. Sizing exists to decide whether an item fits and whether it should be split. Sizing the bottom of the backlog produces numbers that will be wrong by the time they are used, and creates the impression that the list is a forecast.
Splitting by layer. Breaking one item into a database task, an interface task and a test task makes each piece smaller without making any of them finishable on their own. Splitting by outcome, so each piece is something a person could use, is harder and is the only split that reduces risk.
Writing acceptance criteria as a contract. Long criteria lists tend to substitute for the conversation rather than record it. Short criteria plus a named person to ask beats twelve bullet points written defensively.
Refining what has already been decided. If the plan is fixed and the dates are fixed, the session is theatre. Teams in that position are better served by being honest about it and spending the time on sequencing instead, because the order in which fixed work is done is still a real decision with real consequences for who is blocked and when.
Treating the size as a commitment. A size given during refinement is an input to a decision about splitting, and the moment it starts being quoted back as a promise, sizes inflate. The inflation is rational behaviour and it destroys the only thing the number was useful for.
Two signals are enough, and neither is a velocity chart.
The first is what happens in planning. If planning consists of confirming things the team already understands, refinement is working. If planning includes someone asking what an item actually means, it is not.
The second is how often work stops mid flight for a question that could have been asked earlier. Tracking this does not require a tool. It requires someone noticing, for two weeks, each time an item goes back to waiting because something was unclear. Three or four instances in a fortnight on a small team points at the top of the backlog, not at the people doing the work.
Where the record lives affects both signals more than most teams expect. When the refined description, the size, the owner and the current state sit in the same place, the conversation that produced them is retrievable. When the discussion happens in chat and the item lives in a tracker, the reasoning is lost and the next person re opens it. Keeping the board, the schedule and the conversation about the work in one place rather than three removes the most common reason refinement has to be redone.
Stop refining the whole list and refine only the next two weeks of it, with the smallest group of people who can answer questions and decide scope. Add one rule for age, apply it once, and then leave the bottom of the list alone. If the reasoning behind refined items keeps getting lost between a chat tool and a tracker, consolidating them is the higher leverage fix, and Pinateca keeps kanban, Gantt, calendar and timetable views plus discussion on the free tier for up to five people and ten boards.
They describe the same activity, and refinement is the current term. The 2020 Scrum Guide uses refinement and describes it as an ongoing activity rather than a scheduled event, so a team running a weekly grooming meeting is doing refinement with an older name and an added ceremony.
There is no prescribed length because it is not a Scrum event. For a small team, twenty to forty minutes a week with two or three people is usually enough to keep the next couple of weeks ready. If the session regularly runs over an hour, either too many items are being covered or decisions are being deferred inside it.
The product owner is accountable for the backlog being ordered and understood, so they normally convene it and answer questions about intent. Sizing is different: the Scrum Guide puts that with the developers who will do the work, and the product owner influences it only by explaining trade offs.
Enough to cover the work the team will start before the next session, plus a small margin. For a team refining weekly that is usually one to two weeks of items. Going further ahead creates detailed specifications that have to be revisited anyway once the surrounding work changes.
Close them with a note saying they were closed for age, and allow anyone to reopen them. An item that has not been discussed in months will return with better context if it still matters, and keeping it visible makes the list harder to read for everyone who has to scan it.