Sprint planning vs backlog refinement
Sprint planning and backlog refinement are the two preparation events that determine sprint quality. Confusing them leads to poorly run meetings, over-committed sprints, and frustrated teams. This guide explains what each event is, what it produces, and how they work together.
Quick reference: key differences
| Backlog Refinement | Sprint Planning |
|---|---|
| Ongoing throughout the sprint (typically 1–2 sessions per sprint) | Once, at the start of each sprint |
| Ready backlog items: estimated, acceptance criteria written, dependencies identified | Sprint Goal + selected sprint backlog + initial task breakdown |
| Product Owner + full team | Scrum Master facilitates; full team commits |
What backlog refinement does
Refinement prepares future work. Its outputs — refined, estimated backlog items — are the inputs for sprint planning. Without refinement, sprint planning cannot function efficiently because the team spends planning time doing refinement work.
In refinement, stories can be questioned, changed, and removed. The Product Owner can reprioritise. The development team can push back on scope. This flexibility is appropriate in refinement because there is no sprint commitment at stake.
- Writing and reviewing acceptance criteria
- Splitting large stories into sprint-sized items
- Estimating using planning poker
- Identifying and resolving dependencies
- Removing outdated or superseded items
What sprint planning does
Sprint planning commits to a specific plan. The flexibility of refinement narrows: the Product Owner has ordered the backlog, the team has capacity data, and the goal is to agree on a concrete, achievable sprint.
The three required outputs of sprint planning — Sprint Goal, selected backlog, and initial task breakdown — are commitments. They tell the rest of the organisation what the team will accomplish and provide a daily coordination tool for the sprint.
- Agreeing the Sprint Goal
- Selecting backlog items that fit sprint capacity
- Estimating any remaining unestimated items (briefly)
- Breaking down the first 2–3 days of work into tasks
- Confirming the team's commitment
Common mistakes that blur the boundary
The boundary between refinement and planning is frequently blurred. These patterns cause the most problems.
- Estimating during sprint planning: when stories arrive at planning without estimates, the team must estimate before they can select. This typically doubles planning time. Fix: ensure all candidate stories are estimated during refinement.
- Changing acceptance criteria during planning: if the Product Owner uses sprint planning to revise acceptance criteria, the team cannot plan accurately. Criteria changes belong in refinement.
- Skipping refinement "to save time": this is the costliest mistake. One hour of refinement saves two to three hours of planning. Teams that skip refinement consistently overrun planning timeboxes and produce lower-quality sprint commitments.
- Using planning to have refinement discussions: "Wait — what does this story actually mean?" is a refinement question. Teams that normalise this during planning will find their planning sessions expanding indefinitely.
How refinement and planning work together
The relationship is upstream-downstream: refinement produces the inputs that planning consumes. A healthy pipeline looks like this:
- Refinement runs mid-sprint, processing the backlog two sprints ahead.
- Stories exit refinement ready: estimated, acceptance criteria accepted, dependencies resolved.
- Sprint planning selects from ready stories, agrees the Sprint Goal, and produces a sprint backlog.
- The sprint produces velocity data that feeds back into refinement prioritisation.
- The cycle repeats.
Sprint planning vs refinement FAQ
Is refinement a Scrum event?
No. The Scrum Guide describes refinement as an activity rather than a formal event. Teams decide when and how to do it. The only formal Scrum events are the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Can refinement replace sprint planning?
No. Refinement prepares work; sprint planning commits to work. You need both. Refinement without planning produces a well-prepared backlog with no sprint commitment. Planning without refinement produces a rushed commitment built on incomplete information.
Who facilitates refinement vs sprint planning?
Both are typically facilitated by the Scrum Master, but this is a convention, not a rule. The Product Owner often leads the refinement discussions, with the Scrum Master managing the meeting process. Sprint planning is more tightly structured and almost always benefits from Scrum Master facilitation.
How do we know if our refinement is working?
Good refinement shows up in sprint planning: fewer clarifying questions, faster story selection, and planning sessions that end on time. Bad refinement shows up as planning overruns, mid-sprint scope changes, and stories that can't be started on day one.
Use free online planning poker to estimate during refinement