Backlog refinement
Run refinement so the backlog leaves the room ready.
Backlog refinement is where vague ideas become sprintable work: stories tightened, oversized items split, unknowns turned into spikes. Most teams run the conversation well and then lose half of it, because nobody writes down the splits, the criteria and the decisions while they are talking. This page covers how to run the session, and how Backlog.cloud captures its outputs from the conversation itself.
What it is
The session that turns intent into sprintable work
Backlog refinement, still called grooming by teams who picked up the habit a decade ago, is a recurring working session where the team takes the items most likely to enter the next sprint or two and makes them ready. Ready means understood, testable, sized, and small enough to finish. It is not a status meeting and it is not planning. Nothing gets committed here.
The output that matters is a changed product backlog: stories rewritten with real acceptance criteria, one bloated item split into two shippable ones, a spike raised where the room admitted it was guessing. If the backlog looks identical after the session, the session did not happen. People just talked.
Who should be in the room
- Product owner. Brings the candidates, explains intent, makes the priority calls on the spot.
- The engineers who will build it. Not a representative. The people whose estimates will be held against them.
- A testing brain. QA or the engineer who asks "what should the customer see if this fails?" before anyone writes code.
- Nobody else by default. Designers and stakeholders join for specific items, then leave. Twelve people cannot refine anything.
The agenda
A 60-minute refinement that actually refines
The times are a guide, the sequence is not. Understanding before estimating, splitting before sizing, and a read-back at the end. Skip the read-back and you will re-litigate half of it in sprint planning.
- 0 to 5 min1. Pick the candidatesThe product owner names the items being refined today, usually 4 to 8, chosen because they are likely to enter a sprint within the next two. Anything further out is a waste of the room.
- 5 to 15 min2. Walk the first itemThe product owner explains the intent in user terms. Engineers ask what happens at the edges. Nobody estimates yet. The goal is shared understanding of the problem, not the solution.
- 15 to 40 min3. Refine, split, or spikeFor each item the room does one of three things. Tighten the acceptance criteria until the story is testable. Split it if it hides two deliverables. Or admit an unknown and raise a spike instead of guessing.
- 40 to 55 min4. Estimate what is readyOnly items that now meet the Definition of Ready get sized. If the estimate conversation surfaces a new unknown, the item goes back a step. That is the process working, not failing.
- 55 to 60 min5. Confirm what changedRead back the decisions and the actions with owners. This is the part most teams skip, and it is exactly the part that evaporates by the next morning.
What should come out
Five kinds of output, and a bar to hold them to
A good refinement session emits refined user stories with acceptance criteria, split stories, spikes for the honest unknowns, decisions, and action items with owners. Backlog.cloud listens for exactly these five shapes and drafts each one from the words the team actually said. The Definition of Ready below is the bar to hold every story to before a sprint may take it.
A Definition of Ready worth enforcing
- The story states who wants it and why, not just what to build
- Acceptance criteria are numbered, testable scenarios, not adjectives
- It fits inside one sprint for one team, or it has been split
- Dependencies on other teams or systems are named
- Open questions have an owner, or a spike has been raised
- The team has estimated it after discussing it, not before
Six items, on purpose. A Definition of Ready longer than eight lines stops being a quality bar and starts being a reason nothing ever qualifies.
Worked example
Eight lines of refinement, four artefacts
A fictional team refining "upgrade my subscription plan". Watch what the conversation actually produces: a split, tightened criteria, a spike and an owned action. This is what Backlog.cloud drafts while the team keeps talking.
The conversation
Maya (PO): Next one: "As a customer I can upgrade my subscription plan." It has been sitting at the top for two sprints.
Tom (Eng): As written it is two different jobs. Upgrading mid-cycle with proration is one thing. Scheduling an upgrade to start at renewal is a completely different flow.
Maya (PO): Fair. Mid-cycle is the one customers actually ask for, so let us split it and take mid-cycle first.
Aisha (QA): What should the customer see before confirming? If the prorated charge is a surprise we will drown in tickets.
Maya (PO): They must see the exact prorated amount and the new renewal price before they confirm. That is a hard requirement.
Tom (Eng): One unknown. I do not know how the payment provider handles proration for multi-seat accounts. Their docs contradict their sandbox.
Maya (PO): Then that is a spike, not a guess. Timebox it to two days. Tom, can you own it?
Tom (Eng): Yes. I will bring the answer to the next refinement so we can size the multi-seat story properly.
Highlighted statements are the ones the extraction engine anchored artefacts to.
Split story, refined and ready
Upgrade a subscription mid-cycle with prorated billing
As a subscriber, I want to upgrade my plan mid-cycle and see exactly what I will be charged, so that I can move up without a billing surprise.
Acceptance criteria
- Given a subscriber on a lower plan, when they choose an upgrade mid-cycle, then the exact prorated charge and the new renewal price are shown before confirmation.
- Given a displayed prorated charge, when the subscriber confirms, then the charged amount matches the displayed amount exactly.
"They must see the exact prorated amount and the new renewal price before they confirm."
Spike, instead of a guess
Verify payment provider proration behaviour for multi-seat accounts
The provider's documentation and sandbox disagree on how proration applies to multi-seat upgrades. Confirm actual behaviour so the multi-seat story can be sized with evidence rather than optimism.
"I do not know how the payment provider handles proration for multi-seat accounts. Their docs contradict their sandbox."
Also extracted, decision: split "upgrade subscription" into mid-cycle and at-renewal stories, mid-cycle first.
Also extracted, action item: Tom to bring spike findings to the next refinement session.
Where it lands: after review, the two stories and the spike arrive in Jira as typed issues with ADF descriptions and numbered criteria, in Azure DevOps as User Story and Task work items on the right iteration path, or in Linear as prioritised issues on the team's board. Full flow on meeting to Jira.
Common mistakes
Where refinement goes wrong
Refining the whole backlog. Items three months out will change before they are built. Refine the top of the backlog and let the rest stay rough. Detail applied too early is detail thrown away.
Estimating before understanding. When the first question is "how many points?", the room anchors on a number and stops interrogating the work. Understanding first, splitting second, sizing last.
Guessing instead of spiking. An engineer says "probably fine" about an integration nobody has tested, the story gets a 3, and it detonates mid-sprint. Named unknowns become spikes with timeboxes. That is what spikes are for.
The scribe bottleneck. One person tries to update stories live while the discussion moves on, and the criteria they type are a paraphrase of a paraphrase. This is the specific failure Backlog.cloud removes: the conversation itself is the source, every drafted artefact cites the verbatim quote it came from, and a human approves each one before it reaches the backlog.
No read-back. The session ends at 59 minutes with everyone half-agreeing. Two days later, sprint planning reopens every question. Reserve the last five minutes to confirm decisions and owners out loud.
FAQ
Backlog refinement, answered
- What is the difference between backlog refinement and sprint planning?
- Refinement prepares work, planning commits to it. In refinement the team clarifies, splits and estimates items so they meet the Definition of Ready. In sprint planning the team selects ready items against capacity and commits to a sprint goal. Teams that merge the two end up doing discovery inside planning, and planning balloons to three hours.
- How often should backlog refinement happen?
- Once per sprint as a scheduled session works for most teams, roughly 5 to 10 percent of the sprint. Some teams prefer two shorter sessions. The test is simple: if sprint planning keeps stalling on unclear items, you are not refining enough or not refining the right items.
- Who should attend backlog refinement?
- The product owner, the engineers who will build the work, and someone who thinks about testing. Not the whole organisation. Stakeholders feed the product owner before the session. A refinement session with twelve people is a status meeting wearing a disguise.
- What is a Definition of Ready and do we need one?
- It is a short checklist a story must pass before a sprint can pick it up: clear intent, testable acceptance criteria, sized, dependencies named. You need one the moment sprints start absorbing half-understood work. Keep it under eight items or it becomes a bureaucratic gate instead of a quality bar.
- What does Backlog.cloud actually extract from a refinement session?
- Refined user stories with numbered Gherkin acceptance criteria, the split stories when the room breaks one item into several, spikes when someone names an unknown, decisions with their rationale, and action items with owners. Each artefact is anchored to the verbatim quote it came from, and everything waits in a review queue before anything is pushed.
- Does the meeting bot need to be on the call, or can I paste a transcript?
- Either. Paste a Zoom, Microsoft Teams or Google Meet link and the bot joins and transcribes. Or paste the transcript afterwards, or upload a recording or a photo of the whiteboard. The extraction is identical whichever route the conversation takes in.
- Can the extracted stories go straight into our backlog tool?
- After review, yes. Approved items push to Jira, Azure DevOps, Linear, GitHub Issues, Notion or ClickUp with type, priority and labels mapped. Jira descriptions are written in Atlassian Document Format, which is why they arrive formatted instead of mangled.
Keep going
Related workflows and resources
Product backlog guide
Prioritisation, backlog hygiene and Definition of Ready in depth.
User stories
The INVEST standard and Gherkin criteria every story should meet.
Sprint planning meetings
What happens to refined items next, and how to keep planning short.
AI user story generator
Paste refinement notes and get story drafts in the browser.
Jira integration
How approved stories land in Jira: ADF, types, priorities, labels.
Meeting to Jira
The full path from a live conversation to reviewed Jira issues.
Refine out loud. Keep everything.
Backlog.cloud sits in your refinement session, or reads the transcript afterwards, and drafts the stories, splits, spikes and decisions the room produced. Review, then push. 3 free generations, no card.