Refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise ones. It runs continuously through the Sprint rather than at a fixed point, and the Guide gives it no timebox, no format and no attendee list.
Almost everything people believe about refinement comes from common practice rather than from the framework, which is what makes it such a reliable source of confusion.
An activity, not an event
Scrum defines five events, being the Sprint and the four that sit inside it. Refinement is not among them. It has no timebox in the Guide, no prescribed output and no required participants, so a team that skipped its refinement session this week has not broken a rule.
The often quoted figure of ten per cent of the Developers' capacity came from an older version of the Guide, where it was offered as guidance rather than as a limit, and it is absent from the 2020 edition. How much time refinement deserves is for the Scrum Team to work out from how much clarity the next Sprint or two actually needs.
Teams commonly book a recurring session, which is a sensible practice and not a requirement. Nothing stops refinement happening in a conversation between two people or in the minutes after a Daily Scrum, and on a healthy team a good deal of it does.
What refinement adds
Two things happen. Large items are broken into smaller ones, and detail is added to the items that remain, such as a description, order and size. Attributes vary with the domain of work, and the Guide names those three because they are the ones every domain needs.
The state being worked towards is an item the Scrum Team can complete within one Sprint. Items that reach it are deemed ready for selection in Sprint Planning. Readiness is a shared understanding rather than a gate, since Scrum defines no Definition of Ready, and a team that treats one as mandatory has added a rule the framework does not contain.
The Developers who will do the work size it
That wording is exact, and it rules out a manager, a Product Owner or a neighbouring team supplying the number. A size is a statement about how hard something will be for the people who will actually do it, which is also why sizes from one team say nothing useful about another.
The Product Owner is not silent in the conversation. They may influence the Developers by helping them understand and select trade offs, which usually means explaining what the item is really for so that a cheaper version of it can be found. Shaping the understanding is a different act from setting the number.
How far ahead to refine
A Sprint or two of ready items is usually enough. The top of the backlog is fine grained and well understood, and the further down an item sits the coarser it can be, because an item that may never be built does not deserve a specification.
Refining the whole backlog to one level of detail is a familiar failure, and it feels productive while it is happening. What it produces is a large quantity of careful thinking about work whose value has not been tested, most of which will be reordered, rewritten or deleted before anybody builds it.
Why premature detail is expensive
Detail costs more than the hours spent producing it. A heavily specified item resists change, because somebody has invested in it and the specification starts to look like a decision that has already been taken. Feedback arriving afterwards has to argue against that investment rather than simply redirecting the work.
The cheapest item to change is the one that is still a sentence. Refinement is therefore a question of timing rather than thoroughness, and the aim is to add detail at the last point where it is still useful and not before.