Skip to article
Bridge

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.

TimeActivityOutput
5 minProduct Owner recaps the Product Goal and changes in order since last timeShared view of what matters next
35 minWalk the top items: clarify, split and size each oneSmaller items with descriptions and sizes
10 minList open questions and unknownsEach question with an owner
10 minProduct Owner confirms the new orderOrdered 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