Backlog Refinement Meeting Agenda: A 60-Minute Structure and the Rule for What Stays Out

Most backlog refinement meetings die a slow death by scope creep. What starts as a 45-minute check-in on ticket details turns into an hour-long argument about architecture, estimates for stories nobody has written yet, and another round of the roadmap debate everyone thought was settled last quarter. At the end, the Product Owner has a page of scribbled notes and nothing is ready for the next sprint.

I've sat through plenty of these, and in my early years I ran a few of them. The fix is unglamorous: a fixed 60-minute structure, entry criteria each item must pass before it gets airtime, and a rule, stated out loud at the start, about what the meeting will not discuss. This article is that agenda. For the general definition of refinement and where it sits in Scrum, read the backlog refinement guide and the Backlog Refinement method page. I won't repeat them here.

Why refinement needs a fixed timebox

Refinement is one of the few Scrum activities without a prescribed format. The Scrum Guide describes it as an ongoing activity rather than an event, so every team invents its own version. In my experience, an invented format with no structure defaults to whoever talks loudest. That's usually the most senior engineer or the Product Owner, and the quieter developers who will build the thing stop contributing after about fifteen minutes.

There used to be a benchmark. The 2017 edition of the Scrum Guide said refinement 'usually consumes no more than 10% of the capacity of the Development Team.' The current edition dropped the figure, but Scrum trainers still quote it, and Scrum.org's refinement overview keeps describing refinement as a continuous, bounded activity. Treat 10% as a ceiling. Most teams I work with get what they need from one 60-minute session a week, plus PO prep and some async clarification in the ticket comments. That's well under the ceiling, and it leaves developers time to build.

The failure mode of unbounded refinement is predictable. The same three items absorb nearly all the discussion, week after week, while a dozen other stories never get looked at before sprint planning. Then planning becomes refinement, and everything downstream slips.

Backlog grooming vs refinement

'Grooming' was the informal term in early Scrum practice for tidying the backlog: reordering, deleting stale items, light cleanup. 'Refinement' became the official term once the industry recognised the work as a distinct activity, and organisations including Scrum.org retired 'grooming' partly because of its unrelated negative connotations (the Scrum Glossary now uses refinement throughout). Most teams use the two words interchangeably today, and I don't correct anyone who says grooming. The distinction worth keeping is functional. Grooming suggests passive maintenance that one person can do alone. Refinement is active, collaborative preparation of specific items by the people who will build them, which is why this agenda treats it as a working session with entry criteria.

How refinement differs from sprint planning

Refinement is preparatory and continuous. It happens mid-sprint, Scrum mandates no cadence for it, and its output is backlog items that are clearer, smaller and roughly estimated. Sprint planning is a formal, timeboxed Scrum event held once at the start of each sprint, and its output is a Sprint Goal and a Sprint Backlog.

The questions differ too. Refinement asks: is this item understood well enough to estimate and eventually plan? Sprint planning asks: which of these already-understood items do we pull in, and how will we deliver them?

Conflating the two is the most common reason I see sprint planning blow past its timebox. A team walks into a two-hour planning session with unrefined stories and spends the first 30 minutes splitting them and arguing about acceptance criteria. Mike Cohn made the same point years ago in Backlog Grooming or Story Time, Whatever You Call It, Do It: teams that skip refinement discover their unknowns live, in planning, where they are most expensive.

What the Product Owner prepares beforehand

A refinement session is only as good as the PO's prep. When the PO walks in cold and scrolls through Jira looking for 'something we could talk about,' the first ten minutes are gone and the rest of the hour has no shape. I ask POs for the following at least 24 hours before the session:

• An ordered list of candidate items, typically the next one to two sprints' worth, with the top of the list being what the team will see first.
• Known context attached to each item: mockups, links to related tickets, dependencies on other teams, customer quotes.
• Each item tagged either 'ready to refine' or 'needs offline discovery.'
• Open questions that need stakeholder input flagged, with a note on who owns getting the answer.

The tagging does the most work. Roman Pichler recommends that POs screen out items that lack even a basic problem statement, because those need a discovery conversation, and refinement is the wrong room for discovery. When a PO arrives with items already split into those two buckets, I skip the second bucket entirely. Nobody argues, because the PO made the call before the meeting.

Entry criteria for each item

Entry criteria are a short checklist an item must pass before it earns discussion time. Many teams call this a lightweight Definition of Ready; Pichler's piece on the Definition of Ready and Done is a good starting point if your team doesn't have one yet. The set I start teams with:

1. The item has a user story or a clear one-sentence problem statement.
2. Acceptance criteria are drafted, even if incomplete.
3. There is no blocking dependency on an undecided architecture question.
4. It is small enough to fit in a sprint, or it is explicitly flagged for splitting.

The value of a checklist is that the facilitator can say 'this doesn't meet criteria, next' without it sounding like a personal judgment. Judgment calls made in the moment are where refinement drifts into debate.

One condition: the developers co-create the checklist. If the PO or Scrum Master imposes it, the team treats it as bureaucracy and argues with it mid-session. The developers are the ones who have to answer 'do I understand this well enough to estimate it,' so they should write the criteria that define it. Give it one 20-minute slot in a retrospective and revisit it every few months.

The 60-minute backlog refinement meeting agenda

Here is the backlog refinement meeting agenda I use. Five blocks, each with its own timer.

• Minutes 0-5: State the purpose ('make the next items ready'), restate the out-of-scope rule, and confirm the pre-sorted item queue with the PO. If the PO wants to reorder, it happens here, in under a minute.
• Minutes 5-15: Walk the top two or three items against the entry criteria. Items that fail go back to the PO with a note about what's missing. Items that pass move to the next block.
• Minutes 15-45: Discussion and estimation, one item at a time, with a strict per-item timebox of 8 to 10 minutes. The PO explains the problem, developers ask questions, the team estimates.
• Minutes 45-55: Split any item that came out too large, and tighten the acceptance criteria wording on items that are now ready.
• Minutes 55-60: Recap decisions, review the parking lot, assign owners to parked topics, and confirm the next session date.

That math gives you three or four items per session. Teams used to 'covering' fifteen tickets in an hour find this slow at first. Three items that are ready are worth more than fifteen that were nodded through and will be re-discussed in planning.

Timing each block, and the per-item timer

A total meeting length on its own does nothing. Groups expand discussion to fill whatever time is available, which is why Atlassian's guide to timeboxing stresses timeboxes on individual activities. Put a visible timer on each block and on each item. When the 8-minute buzzer goes on a story that is still contested, I say 'let's park this and take it offline,' and I move on. That single habit rescues more refinement sessions than anything else I know.

For the estimation itself, use whatever your team already trusts. Planning Poker works; so does agile T-shirt sizing if your team prefers relative buckets over numbers. Pick one and stop debating the scale.

I build this agenda once as a reusable template in Workshop Weaver, with the five blocks and their durations fixed, so the facilitator isn't reconstructing the structure from memory every week. A published agenda also sets expectations; as I argued in Your Agenda Is a Promise, time blocks are a commitment to the people in the room.

The parking lot

Keep a visible parking lot in the shared document or on the whiteboard. Tangents from the discussion block go there with the name of whoever raised them. In the last five minutes, every parked item gets an owner and a next step. A parking lot with no owners is a bin, and the team learns quickly that 'parking it' means 'ignoring it.'

What stays out of refinement

The rule I read aloud at the start of every session: refinement stops at 'do we understand the problem, and roughly how big is it?' Anything past that line goes elsewhere. Three categories cross it most often.

Solution design

How the engineering will be built belongs in a technical spike or a separate design conversation. Full solutioning in refinement turns into a debate that only two or three people in the room can contribute to, while everyone else checks email. When a developer says 'well, we could build this three different ways,' my response is: 'Good. Let's make that a spike, and bring back a recommendation.' The item gets estimated as a spike, or it goes back to the queue until the spike is done.

Estimates without a story

Estimating an item that has no story and no acceptance criteria is out of bounds. The number has no basis, and placeholder estimates have a habit of being quoted back to the team months later as commitments. If someone asks 'can we just put a rough number on it,' the answer is to send it back through the entry criteria.

Roadmap and priority debates

What to build next quarter, whether the strategy needs to change, whether this feature matters at all: these are leadership and PO conversations that happen outside refinement. The session accepts the priority order the PO brought into the room. If a developer believes the order is wrong, that's a legitimate concern, and it goes on the parking lot with the PO as owner. It does not get argued for 20 minutes while the queue waits.

Facilitation habits that hold the agenda

Name a facilitator who is not also representing the PO's priorities or the developers' technical views. Often that's the Scrum Master, but a rotating developer works if the Scrum Master is too close to the content. Someone arguing about scope cannot credibly enforce a timebox on scope arguments.

Restate the agenda and the out-of-scope rule at the start of every session, including the fortieth one. It feels repetitive. It also gives the facilitator social permission to interrupt at minute 22 without looking arbitrary, because the group agreed to the rule twenty minutes earlier.

Project the agenda or keep it open in a shared tab for remote sessions. Teams running refinement from memory get far more 'wait, what are we doing right now' moments than teams who can see the current block and the timer. My earlier guide on how to facilitate an effective backlog refinement session covers the remote setup in more detail.

End with a written recap: which items are now ready, which were split and into what, which were sent back and why, and what's parked with whom. The PO updates the backlog from that recap within the hour, while the decisions are fresh.

Treat the agenda as a discipline and run it unchanged for three sprints

The 60-minute structure and the out-of-scope rule are there to protect the team's attention for the one job refinement exists to do: making the next items ready. The timeboxes will feel tight in the first session, and someone will ask for more time on an item that deserves it. Park it, and trust the process.

Before your next session, sit down with the team and write or update your Definition of Ready, then use the backlog refinement guide to adapt the entry criteria to your context. After that, run this agenda exactly as written for three sprints. Track how many items leave each session ready and how much of sprint planning goes to ad hoc refinement. Only then adjust the timeboxes, and change one block at a time so you can tell what made the difference.