How to run a backlog refinement session that feeds planning
Backlog refinement is the ongoing work of breaking Product Backlog items into smaller, more precise items and adding detail such as a description, order and size. The Scrum Guide doesn't make it a meeting, but a team can choose to hold a regular session for it. The aim is simple: the top items should be small and clear enough to finish within one Sprint.
What the Scrum Guide says, and what it leaves to you
The 2020 Scrum Guide calls refinement an ongoing activity, and says the Product Backlog is refined as needed during the Sprint. It isn't one of Scrum's five events, so there's no required meeting, timebox or share of the Sprint to spend on it.
Three points are fixed:
- The Developers who will do the work are responsible for sizing it. The Product Owner can help them understand trade-offs.
- The Product Owner is accountable for the Product Backlog: creating and ordering items and keeping it understood. They may delegate the work but stay accountable.
- Items that can be Done within one Sprint are ready for selection in Sprint Planning. They usually get there through refinement.
When a regular session helps
Some teams refine in small chunks as work comes up. A scheduled session helps when Sprint Planning keeps stalling on items nobody understands, or that turn out far too big.
One option is a single session per Sprint, held a few days before Sprint Planning. That leaves time to chase the answers the session uncovers.
Who attends and what to bring
Send the items a day ahead. People ask better questions about something they have already read.
- Product Owner: the next items in order, why each matters, and how they relate to the Product Goal.
- Developers who will do the work: the Definition of Done, and anything learned recently that changes effort or risk.
- Scrum Master, if useful: help with refinement techniques and keeping the session focused.
- Invited experts: a designer, analyst or stakeholder for a specific item, only for that part of the session.
A sample 60-minute agenda
This is an illustrative format. Adjust it to your backlog and Sprint length.
| Time | Activity | Output |
|---|---|---|
| 5 min | Product Owner recaps the Product Goal and changes in order since last time | Shared view of what matters next |
| 35 min | Walk the top items: clarify, split and size each one | Smaller items with descriptions and sizes |
| 10 min | List open questions and unknowns | Each question with an owner |
| 10 min | Product Owner confirms the new order | Ordered backlog for Sprint Planning |
How to split an item that's too big
Split so each piece still delivers something a user or stakeholder can see. Splitting by technical layer, such as "database" then "interface", leaves pieces that can't be Done on their own.
- By workflow step: sign-up first, password reset later.
- By rule or case: the simple case first, then each exception.
- By data or channel: one file format, region or device before the rest.
- By unknown: if nobody can size it, take a small time-boxed investigation first.
Example: refining "customers can export their invoices"
This example is illustrative. The Developers can't size the item because exports could mean PDF, CSV or a bulk download for accountants.
The Product Owner says single-invoice PDF matters most for the Product Goal. The team splits it into three items: download one invoice as PDF, export a month as CSV, and bulk export for accountants.
The PDF item is sized and fits easily in one Sprint. The CSV item needs an answer on which columns finance wants, so the Product Owner takes that question. Bulk export stays large and lower in the order.
What "ready enough" looks like
The Scrum Guide's test is that an item can be Done within one Sprint. You can add your own working checklist, but keep it light, or refinement becomes a gate.
A useful check for the top items:
- The Developers who will build it have sized it.
- It fits within one Sprint with room to spare.
- Everyone can say what Done looks like for it, given the Definition of Done.
- Known dependencies and open questions are named, with owners.
What the session should leave behind
Update the backlog itself during or right after the session. Notes that never reach the backlog won't help Sprint Planning.
- An updated Product Backlog order, confirmed by the Product Owner.
- Top items split, described and sized by the Developers.
- Open questions, each with an owner and a date to answer by.
- Items removed or pushed down, with a one-line reason.
Refinement sessions in Bridge
Host the session on Bridge, or capture it from Zoom, Google Meet or Teams. The notes give you a summary, decisions and follow-ups, so open questions and their owners don't get lost.
Add a custom label such as "Refinement" to find these sessions later. Put them in the same space as your Sprint Planning meetings, so the team can trace why an item was split or reordered.
Sources & further reading
- The 2020 Scrum Guide: Product Backlog, refinement and Definition of Done ↗
- Bridge help center: Host a meeting on Bridge ↗
- Bridge help center: Capture a virtual meeting outside Bridge ↗
- Bridge help center: Notetaking (summary, decisions and follow-ups) ↗
- Bridge help center: Labels ↗
- Bridge help center: Spaces ↗




