Short answer: A backlog refinement meeting prepares upcoming stories for sprint commitment. The working agenda: review priorities (5 min), walk through next-up stories with clarification (25 min), estimate (15 min), split too-big stories (10 min), confirm ready set (5 min). 60 minutes is enough for most teams. Three signs the meeting is drifting: it runs over without finishing, no stories are being marked ready, and the team starts skipping it.
A backlog refinement meeting takes place as a scheduled working session where the team gets the top of the backlog ready for the sprint commitment. The purpose is to discuss our priorities, clarify walk through next-up stories, estimating and splitting too-big stories, and confirming ready set. A sixty-minute session every week during the two-week sprint cadence.
When a sprint planning meeting overruns it usually means there’s a missing refinement meeting. The team has stories that are not yet clarified or estimated on which they plan their sprint so planning becomes a clarification session which takes hours instead of minutes A working refinement meeting takes that work and absorbs it in a regular weekly slot, where it can be done well. The Scrum Guide treats refinement as an ongoing activity, not a one-off ceremony.
The working agenda, who should attend, how long we will stay in there, when the meeting is drifting into theatre and when to scale it differently. This is for Scrum Masters and Anchors fixing or setting a refinement cadence.
The working agenda
A weekly team refinement meeting for a five-to-seven-member-team running two-week sprints.
- Priority review (5 min). PM walks through any priority changes since the last meeting. Anything new at the top? Anything pushed down?
- Story walk-through (25 min). Read through the top 8–12 stories. PM presents intent; engineers ask clarification questions; acceptance criteria get added or updated; questions that need offline answers get assigned to the PM.
- Estimation (15 min). Story-point estimation for the walked-through stories. Planning poker or similar; reach consensus or document disagreement. We have a healthier approach to estimating velocity that pairs well with this.
- Splitting (10 min). Identify stories larger than ~8 points; split them into smaller stories. Splitting stories across teams goes deeper on the patterns; Martin Fowler’s user story patterns cover the vertical-slice rationale. Document the splits in the tracker.
- Confirm ready set (5 min). Final list of stories that are now "ready" for sprint commit. Anything left unresolved goes back into the un-refined queue for next time.
Overall Time: 60 minutes. The time allocated for a particular task depends upon how well the team starts getting into the groove of the planning. When estimation goes fast, greater time will go to splitting, or, when the stories are clear, greater time will go to priority discussion.
If you are on a 1-week sprint cadence, you can have two 30-minute sessions per week instead of one 60-minute. If sprints last three weeks, make it 90 minutes every week. The proportion is about the same ~10% of team time on refining. Atlassian’s reference on backlog refinement cadence lands on a similar window.
Who attends
List of attendees.
- PM / Product owner. Drives the agenda, owns the stories.
- Engineering lead / anchor. Facilitates the technical conversation.
- Two or three engineers (rotating across refinements).
- Optional: QA representative.
- Optional: designer, if design-relevant work is up.
A rotating roster where two or three engineers go to refinement sessions ensures everyone gets exposure every month. Not every member of the team attends every meeting that takes place that can be quite expensive!
External stakeholders, executives, marketing, sales are not present in the rooms The PM incorporates their input into the backlog; they don’t need to attend refinement.
The time-box that holds
The sprint time is 60 minutes for a 2-week sprint; however, the time scales proportionately.
| Sprint length | Refinement frequency | Per-meeting duration |
|---|---|---|
| 1 week | 2× per week | 30 min each |
| 2 weeks | 1× per week | 60 min |
| 3 weeks | 1× per week | 90 min |
| 4 weeks | 2× per fortnight | 60 min each |
The overall is approximately 10% of the team's calendar time, across all formats. If stories aren’t refined enough, the proportion should be less than 5%. On the other hand, it should be more than 15% if the team is grooming faster than they are building.
Holding a time-box is tougher than it might seem. The refinement meetings tend to extend 90 minutes, then 120 minutes, and into “we’ll finish with this next week.” The solution is to end on schedule. Items that are unfinished will be reprioritized. Due to time constraints in the meeting, prioritisation is unavoidable; if there was unlimited time, it wouldn’t be a meeting. For more on how much refinement is enough, see finding the right amount of backlog refinement.
What "ready" actually means
The story has the "desired" level of detail, which is the exit condition. The explanation
- Acceptance criteria are written in user-observable terms, following principles of effective story writing.
- Story points are assigned (consensus or documented disagreement).
- Size is appropriate — typically 1–13 points; anything larger should have been split.
- Open questions are documented with owners and target answer dates.
- Dependencies are surfaced — if this story needs an API from another team, the team knows.
Without these, a story isn't ready. The failure case in which a team's planning gets wasted is putting it in a sprint anyway.
RUBY-ZO0DPD-EPXFLBIE4H is built on just this distinction. Stories without estimates (blue or grey) or story owners (red or orange) visually stand apart from stories that are ready (green). You can’t accidentally put unrefined work into a sprint because of the structural cue.
Three signs the meeting is drifting
Patterns of failure become predictable after host of refinement meetings.
1. The meeting runs over without finishing.
The agenda consists of eight stories and the team manages to get through three of the stories. The remaining five stories are pushed to next week where eight new stories are added. "To be refined" backlog keeps growing; meeting is falling further behind.
The solution is tighter agendas. Reduce the number of stories per meeting (more passes, less depth) or split the meeting into two shorter ones (estimation in one, splitting in another).
2. No stories are being marked ready.
All members of the team discuss the story at length and ask questions. They surface dependencies. They never, however, declare anything ready. All items remain in the "to be refined" status. During the next sprint planning, the team is selecting from a pool that’s not more refined than the previous one.
Enforce the exit condition to fix it. In a 60-minute meeting, the facilitator says at minute 55: “What’s ready to go in the next sprint?” and the team picks. The stories that are not ready go back to unrefined.
3. The team starts skipping it.
Attendance falls. Conflicts emerge at engineers. The meetings change from weekly to on-demand meetings. The team indicates that the meeting does not deliver value.
Solution: Inquire about the reason. The meeting format is flawed if the outcome is useless. If definition of done (DOD) of stories is getting too flexible, reduce frequency. Rearrange the rotation if the attendees are incorrect. Skipping indicates an issue, but the diagnosis depends on context.
The mathematics behind reducing story size is that cycle times drop from days to hours, and teams reach users up to 14× faster and this maths depends on the refinement meeting generating actually-ready stories. Lengthy vague tales cost time. Well-defined small stories are fast. The refinement meeting occurs before the speed metric.
The most common refinement meeting failure
As we observe more and more teams, we noticed a dominant failure: the meeting happens, but the team sees it as "discussion time" and not "commitment time". Discussions occur but readiness for making does not. The condition for exit is vague. The backlog grooming skills every PM should master come back to the same exit-condition discipline.
To stop the never-ending burger stories, we need a clearer definition of a ‘ready’ state. Using a checklist, ideally as a story – equally applied to every story before the meeting ends.
A second failure occurs when the meeting is too late. The team clarifies the stories for the present sprint, not the next one. The team races always a week behind on refinement; thus, a permanent scramble ensues.
Refining beforehand can help in fixing issues. The meeting this week will have stories that are candidates for next sprint, not this one. When the team is continuously refining for the ongoing sprint, the meeting should occur further ahead in the cadence.
A real opinion on refinement format
Most teams add too much formality to refinement. Using elaborate tools, organized story formats, and essential acceptance-criteria templates for planning poker. This formalisation lets the conversation be a little slower.
It is a meeting with the right level of formality where the team reads the stories, discusses them, aligns on points, and writes down what was agreed. The tools are any tooling the team uses for stories (JIRA, Linear, LiteTracker, etc.) plus a video call. There are no additional tools or processes necessitated.
Teams do great refinement often but not in a formal way. They do it consistently, with a clear exit condition, time-boxed, and skip it when the stories are obvious.
When the meeting isn't worth running
Genuine accountabilities.
- Pure kanban flow. No sprint boundary; refinement happens just-in-time as stories approach the top of the queue.
- Solo engineer. Reading the backlog is refinement; no meeting needed.
- Pre-PMF startup. The work changes too fast; formal refinement is overhead.
- Pure operations team. Tickets flow in and get triaged daily; no separate refinement cadence.
For the product teams of 4+ engineers that use sprints yes, run refinement. Maintain the timeline. Implement the end condition.
Frequently asked
What is a backlog refinement meeting?
A meeting where the entire team collaborates to prepare the top of the backlog for the sprint commitment. The agenda includes reviewing priorities, going through stories, estimating, splitting, and confirming ready set. The 60-minute meeting occurs weekly during a two-week sprint cadence.
Who attends backlog refinement meetings?
The team generally consists of a PM/product owner, engineering lead/anchor, two to three engineers. The PM externally accounts for the stakeholders’ input in the backlog; they are not in the meeting.
How long should a refinement meeting be?
For sprints lasting 2 weeks, the recommended time is 60 minutes, while for 1-week sprints, it is 30 minutes twice a week. Finally, for 3-week sprints, it is 90 minutes weekly. Essentially 10% of the calendar time of the total teams.
What's the agenda for a refinement meeting?
Priority critique (five minutes), review with Q&A, which requires the team to go through it together (25 minutes), estimate (15 minutes), split too-big stories (10 minutes), confirm set is ready (5 minutes). Ratio adjustments depend on how 'ready' the stories are to get going.
What's the goal of a refinement meeting?
A set of stories ‘ready’ for the team to commit to in the next sprint planning. When a story is ‘Ready’, it has clear acceptance criteria, it has assigned story points, it is appropriately sized (1-13 points), it’s documentation lists any open questions, the documentation flags any dependencies that may exist.
How is a refinement meeting different from sprint planning?
Refinement Readies Stories for Commitment; Sprint Planning Commits to Them. Continuous refinement takes place throughout sprints, while planning occurs at the beginning of each sprint. When done well, planning becomes a fast commitment meeting as refinement has produced ready stories.
What if the meeting runs over?
Complete as scheduled. Anything pending will be carried over to next week's meeting. A meeting that overruns schedule means the agenda is too big for the time allocated. Reduce the number of stories per meeting and/or break the meeting into two shorter meetings.
What if the team starts skipping refinement?
Identify the cause If the stories in the meeting are obvious, it isn’t creating value, so cut down on the frequency of the meeting. Change the format if it is wrong. If the wrong people are there, rotate. Don't just skip; act on the cause.
Still stuck
A meeting that makes sprint planning efficient is backlog refinement meeting. 60 minutes every week over a 2-week period with a clear agenda and exit condition: ready stories for next sprint. The real need for most teams complaining about overrunning planning is refinement, not better planning.
LiteTracker incorporates structural cues like a tracker where refined and unrefined stories can be visually distinguished so that the exit condition of the meeting is observable. If your team is solo, pre-PMF, or in pure kanban flow, formal refinement meetings are probably overhead –refine just-in-time and skip the calendar entry. Free tier, unlimited users.
Regardless of the approach: stick to the time-box, enforce the exit condition, and allow for quick planning.