10.3 Product Backlog Refinement
Key Takeaways
- Product Backlog refinement is the ongoing activity of breaking down and further defining Product Backlog items by adding detail such as description, order, and size
- Product Backlog items are ready for selection when a Scrum Team can complete them to Done within one Sprint
- Refinement is essential ongoing work; the Scrum Guide does not define it as a formal Scrum event with a fixed timebox
- The Product Owner and Developers collaborate on refinement; Developers who will do the work are responsible for sizing
- More precise and detailed items sit toward the top of the Product Backlog; lower items may remain larger and less refined
10.3 Product Backlog Refinement
Scrum Guide 2020: 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. Attributes often vary with the domain of work. The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Refinement is how an emergent backlog becomes actionable without becoming a waterfall specification. PSPO I tests whether you treat refinement as continuous collaboration—not as a missing fifth formal event, not as a PO-only writing exercise, and not as endless analysis of items that will never reach a Sprint.
What Refinement Is
Refinement (sometimes called grooming in older materials—prefer refinement for exam language) is the ongoing activity of:
| Action | Purpose |
|---|---|
| Break down large items | Create smaller, more precise items that can be understood and completed |
| Further define | Clarify intent, acceptance ideas, constraints, and value |
| Add description | Enough detail for shared understanding |
| Add / update order | Keep sequence aligned with value and Goal as learning improves |
| Add size | Developers size so forecasting and selection are grounded |
Attributes “often vary with the domain of work.” Software items may use acceptance criteria and technical notes; other domains may use different clarity mechanisms. Scrum does not freeze a universal item template.
Emergent detail, not big design up front
Refinement does not mean fully specifying the entire Product Backlog. The Guide’s model is that the rest of the Product Backlog emerges to fulfill the Product Goal. Refinement focuses energy where it pays off—typically near-term items—while leaving lower items coarser.
| Healthy refinement | Unhealthy refinement |
|---|---|
| Top items ready for the next Sprint(s) | Entire multi-year backlog detailed to task level |
| Split only when it improves clarity or Sprint-fit | Split into micro-tasks that destroy outcome focus |
| Update order as understanding changes | Detail without rethinking order or value |
| Drop items that no longer make sense | Never delete; only add detail forever |
Ready for Selection: Done in One Sprint
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
This is the practical readiness bar:
- Ready for selection ≈ the Scrum Team can complete the item to the Definition of Done within one Sprint
- Not “ready” because a template checkbox was ticked while the item still cannot be finished in a Sprint
- Not “ready” because it has a user-story format if it is still an epic-sized lump
Relationship to optional “Definition of Ready”
Many teams use a Definition of Ready as a working agreement. That can be fine as a technique. It is not a Scrum Guide artifact or a substitute for Definition of Done. On the exam:
- Definition of Done = quality commitment of the Increment (formal Guide concept)
- Ready for selection = can be Done in one Sprint (Guide idea)
- Definition of Ready = optional practice; do not treat it as required Scrum law or as more important than Done
If an item is selected but cannot be completed to Done, transparency suffers—work returns to the Product Backlog for future consideration when unfinished, and the Increment must not include undone work presented as complete.
Not a Formal Scrum Event (But Essential)
The five formal Scrum events are:
- The Sprint (container)
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Product Backlog refinement is not listed as a sixth formal event with a Guide-mandated timebox. It is still essential ongoing work.
| Formal event | Refinement |
|---|---|
| Timeboxed by the Guide | No single Guide-prescribed timebox for refinement as an event |
| Required Scrum ceremony structure | Ongoing activity; teams choose how and when |
| Attendance rules in the Guide | Collaboration pattern: PO + Developers (and others as useful) |
Practical time investment
Many teams spend a portion of capacity each Sprint refining upcoming items (a common rule of thumb in older training was on the order of 10%—useful practice, not a Guide law). On PSPO I, prefer answers that say refinement is ongoing and as needed over answers that invent a mandatory sixth event of exactly two hours every Thursday.
When refinement happens
- Throughout the Sprint, as conversations and short workshops
- Not only inside Sprint Planning (Planning assumes attendees are prepared to discuss important items)
- Not only in Sprint Review (Review may adapt the backlog, but deep breakdown is usually ongoing)
If the team arrives at Planning with huge unclear items every time, refinement is underinvested—not “Scrum is failing because we lack a formal refinement event.”
Who Collaborates: Product Owner and Developers
Refinement is collaborative:
| Role | Contribution in refinement |
|---|---|
| Product Owner | Clarifies value, Product Goal alignment, desired outcomes, order, trade-offs; ensures items are understood |
| Developers | Clarify feasibility, break down technical/product slices, identify dependencies and risks, size the work |
| Scrum Master | Coaches the team on effective refinement practices; does not become the orderer or the sole item author |
| Stakeholders / users | Provide input when invited; do not seize PO accountability |
Developers size
The Guide is explicit: Developers who will be doing the work are responsible for sizing. The Product Owner may influence by helping them understand trade-offs (for example, thinner slices, optional scope, quality constraints already covered by Done).
| PO may | PO should not |
|---|---|
| Explain outcome so sizing is informed | Force a story-point number on Developers |
| Suggest splitting for value/risk | Estimate hours for the team as the sizing authority |
| Order smaller high-value slices first | Use size as a weapon to demand more output |
Sizing supports forecasting and selection; it is not the definition of value. A small low-value item can still rank below a larger high-value item after PO judgment—unless risk/learning says otherwise.
Description, Order, and Size—What “Add Details” Means
Description
Enough shared understanding of:
- What outcome or capability is sought
- Why it matters (value / Goal link)
- Constraints and non-negotiables
- How the team will know it is complete enough relative to Done and any item-specific acceptance ideas
Description is not a 40-page requirements document for every item. It is clarity for complex work—enough to plan a Sprint-sized slice without constant reinterpretation.
Order
Refinement often changes order:
- Splitting reveals a dependency that must come first
- Learning shows a risk item should rise
- A large item becomes several children with different relative value
Order remains Product Owner accountability even when Developers facilitate workshops.
Size
Size can be relative (story points, t-shirt sizes) or other team-chosen approaches. Scrum does not mandate story points. What matters is that Developers size, and that size informs whether an item fits a Sprint when combined with the Sprint Goal and capacity.
Top of Backlog More Precise; Bottom Coarser
This gradient is classic Scrum backlog shape:
TOP → small, clear, ordered, sized, ready for selection (Done in one Sprint)
MIDDLE → emerging detail; some splits underway
BOTTOM → larger, vaguer options; cheap placeholders OK
Why the gradient matters
- Protects capacity — do not refine everything equally
- Supports emergence — bottom items may be deleted after learning from top items
- Improves Planning — Developers can select work they understand
- Reduces waste — detailed analysis of abandoned ideas is expensive
Exam trap: “All Product Backlog items must be fully refined and Sprint-sized at all times.” That fights emergence and wastes effort.
Refinement and the Product Goal
Refinement should prefer the path that fulfills the Product Goal:
- Identify what “future state” progress looks like next.
- Break work into inspectable slices that can become Done Increments.
- Order those slices for value, risk, and learning.
- Leave unrelated branches coarse or remove them.
Refining a popular feature that does not serve the Goal—while Goal-critical items stay huge and unclear—is a Product Owner management failure even if workshops are well facilitated.
Refinement Anti-Patterns
| Anti-pattern | Better |
|---|---|
| PO writes perfect specs alone, throws them over the wall | PO + Developers refine together for understanding |
| Refinement only as a formal 4-hour weekly event that replaces conversation | Ongoing activity; use workshops when useful without inventing Guide-mandated events |
| Developers size by the PO’s forced estimates | Developers size; PO clarifies trade-offs |
| “Ready” means template complete, not Sprint-completable to Done | Ready ≈ can be Done in one Sprint |
| Refine bottom of backlog for months | Focus near-term items |
| No refinement; all discovery in Planning | Planning suffers; Sprint Goals weaken |
| Refinement used to pressure scope expansion mid-Sprint without negotiation | Scope changes to the Sprint Backlog are negotiated; Sprint Goal protected |
How Refinement Connects to Events
| Event | Link to refinement |
|---|---|
| Sprint Planning | Assumes important items are refined enough to discuss and select |
| Daily Scrum | May surface need to clarify an item; not the main refinement forum |
| Sprint Review | Adapts Product Backlog; may spawn new items needing future refinement |
| Sprint Retrospective | Improves how the team refines (quality of collaboration, readiness, waste) |
Product Owners who skip refinement and then blame Developers for “not committing to enough scope” are misdiagnosing the system.
Quick Self-Check
- Refinement = ongoing break down and define; add description, order, size
- Ready for selection when item can be Done in one Sprint
- Not a formal Guide event with a fixed timebox—but essential
- PO and Developers collaborate; Developers size; PO influences via trade-offs and clarity
- More detail at the top; coarser at the bottom
What is Product Backlog refinement according to the Scrum Guide 2020?
When are Product Backlog items considered ready for selection in Sprint Planning?
Who is responsible for sizing Product Backlog items during refinement, and how may the Product Owner participate?