Refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise ones. The activity runs continuously through the Sprint, and the Guide gives it no timebox, no format and no attendee list.
Almost everything people believe about refinement comes from common practice, and the framework says far less than they expect, which is what makes refinement such a reliable source of confusion.
Refinement as an ongoing activity
The first thing common practice gets wrong is treating refinement as an event. Scrum defines five events, which are the Sprint and the four that sit inside it. Refinement is absent from that list, so it has no timebox in the Guide, no prescribed output and no required participants, and 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, which offered it as guidance and never as a hard limit, and the 2020 edition drops it altogether. The Scrum Team works out how much time refinement deserves from how much clarity the next Sprint or two actually needs.
Teams commonly book a recurring session, which is a sensible practice that the framework never requires. 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 in refinement. Large items are broken into smaller ones, and detail is added to the items that remain, such as a description, order and size. Attributes often vary with the domain of work, and the Guide names those three because they are the ones every domain needs.
What refinement works towards is an item the Scrum Team can complete within one Sprint, and items that reach that state are deemed ready for selection in Sprint Planning. Ready here is a shared understanding and never a gate, because Scrum defines no Definition of Ready, and a team that treats one as mandatory has added a rule the framework does not contain.
Sizing belongs to the Developers who will do the work
Size is one of the three details refinement adds, and the Guide is exact about who supplies it. Responsibility for the sizing sits with the Developers who will be doing the work. That wording rules out a manager, a Product Owner or a neighbouring team supplying the number, because a size says how hard something will be for the people who will actually do it. The same reasoning is why a size agreed by one team says nothing about how long the same item would take another team.
The Product Owner is not silent in that conversation. The Product Owner may influence the Developers by helping them understand and select tradeoffs, which usually means explaining what the item is really for so that a cheaper version of it becomes possible. Shaping the understanding is a different act from setting the number.
The Scrum Master's part in refinement
The Scrum Master has no number to set either, and no event to run, because refinement is not an event. Nothing in the Guide asks a Scrum Master to ensure refinement happens, to hold it inside a timebox or to decide who attends, since those duties attach to the five events and refinement sits outside them.
A good deal remains. Helping the Scrum Team understand the need for clear and concise Product Backlog items is one of the four services the Guide names to the Product Owner. A team arriving at Sprint Planning with nothing selectable therefore has an impediment, and causing its removal is the Scrum Master's service to the team. A Scrum Master asked to run a refinement session may do so, and the content of the items stays with the Product Owner and the Developers.
How far ahead the Product Backlog needs refining
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. The product of that effort is a large quantity of careful thinking about work whose value nobody has tested, and most of it 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 before it can redirect the work.
The cheapest item to change is the one that is still a sentence. Refinement is therefore a question of timing, and the aim is to add detail at the last moment when it is still useful.