In 30 seconds
- Refinement keeps the top of the backlog ready to work on.
- Items get split, clarified, estimated and reordered.
- A common rule of thumb is about 10% of the team's time.
What happens
- Split large items into smaller user stories.
- Add or sharpen acceptance criteria.
- Estimate, for example with Planning Poker.
- Remove items that no longer matter.
- Let the Product Owner reorder based on what was learned.
How much and how often
Scrum treats refinement as an ongoing activity rather than a fixed event. Many teams hold one or two short sessions per sprint and aim to keep one to two sprints' worth of items ready at the top of the Product Backlog.
Signs it isn't working
- Sprint Planning drags on for hours.
- Stories arrive in the sprint with open questions.
- Estimates swing wildly once work begins.
Myth vs reality
Myth · Refinement is a Product Owner task.
Reality · The Developers' input on size and approach is essential.
Myth · Refine the whole backlog.
Reality · Only the top needs detail; the rest can stay rough.
Myth · Refinement is a waste of sprint time.
Reality · Skipping it moves the same work into a slower, longer planning.
The AI angle
With faster building, refinement becomes the main bottleneck. AI can draft splits and criteria, but humans must agree the intent before work is handed to people or agents.
FAQ
Is refinement an official Scrum event?
No. It's an ongoing activity; teams schedule it however suits them.
Who attends?
The Product Owner and the Developers; stakeholders or experts join as needed.
What does "ready" mean?
Small enough to finish in a sprint, understood, and with clear acceptance criteria.