LeSS Events

Product Backlog Refinement

In LeSS, Product Backlog Refinement is the critical event for cross-team learning and customer connection. It happens in both multi-team and single-team formats, with teams working directly with real customers and users — not through requirement documents.

Multi-team & single-team · Timebox: ~10% of Sprint capacity

Overview

In LeSS, Product Backlog Refinement is the critical event for cross-team learning and customer connection. It happens in both multi-team and single-team formats, with teams working directly with real customers and users — not through requirement documents.

Event Ownership

Owned / Facilitated By
Product Owner (facilitates customer access) / Teams (do the refinement work)
PO connects teams directly with real customers, users, and stakeholders
Teams do the actual refinement work — understanding, estimating, splitting items
PO provides strategic context but doesn’t write detailed requirements for teams
SMs coach teams in effective refinement techniques

Who Should Be Present

Multi-Team PBR
Multiple teams together with PO, customers/users. Used for items that affect multiple teams or require shared understanding
Single-Team PBR
One team with PO (or customer/user). Used for items specific to one team’s upcoming work
Product Owner
Facilitates access to customers. Provides priority and value context. Available for questions
Customers/Users
Participate directly — explain needs, answer questions, provide feedback on proposed solutions

Preparation Checklist

01PO: Identify items needing refinement in upcoming 2–3 Sprints
02PO: Arrange customer/user participation for refinement sessions
03Teams: Review items before refinement sessions
04SMs: Ensure refinement is scheduled and teams understand the format

Facilitation Techniques

Click any technique to expand details and learn when to apply it.

Multi-Team PBR with Customer Panel

Bring 2–3 customers/users to a session with all teams. Customers explain their needs directly. Teams ask questions, explore solutions, and split items collaboratively.

Click to expand

Diverge-Merge

Start with all teams together for context (diverge). Then teams refine specific items independently (merge). Reconvene briefly to share findings and dependencies.

Click to expand

Tips & Tricks

01
Teams do the refinement — the PO facilitates access to customers, not requirements
02
Multi-team PBR is where cross-team learning and coordination happens naturally
03
If refinement quality is high, Sprint Planning becomes short and smooth
04
Design dependencies away during refinement — don’t just identify them, eliminate them
05
Spend ~10% of Sprint capacity on refinement — this is an investment, not overhead
06
Customer/User Relationship Building
The PO should maintain ongoing relationships with real customers and users who can participate in refinement. A roster of 5–10 available customers makes refinement sessions rich and productive.

Success Takeaways by Role

What each participant should walk away with when this event is run well.

Teams

Deep understanding of upcoming work from direct customer interaction; confidence in estimates; reduced surprises in Sprint Planning

Product Owner

Items ready for prioritization; cross-team dependencies visible; teams aligned on upcoming work

Goal

Items refined to a level where teams can self-select and plan them in Sprint Planning

Goal

Dependencies between items identified and designed away where possible

Goal

Teams have direct understanding from customers, not secondhand requirements

Goal

Estimates created by the teams who will do the work