Sprint planning is the scrum ceremony that sets the trajectory of the next sprint — what the team will build, how much they will commit to, and what definition of done looks like for each piece of work. When it works well, it is a focused, energised conversation where the team analyses a well-understood backlog, sets a clear sprint goal, and makes a confident, data-based commitment to a realistic amount of work. When it does not work well — when stories are unclear, estimates do not exist, capacity has not been calculated, and dependencies have not been mapped — it produces a sprint backlog that was assembled under time pressure and is under-committed or overcommitted before the first task starts. The difference between these two outcomes is almost entirely preparation. A structured sprint planning checklist ensures the prerequisites are met before the meeting starts, the ceremony runs to its intended purpose (commitment and task breakdown, not refinement), and the sprint begins with a clear, shared goal and a realistic, team-owned commitment. This free checklist gives scrum masters, product owners, and development teams a structured framework for the full sprint planning process.
The product owner decides the order and relative importance of backlog items. The team decides how much they can realistically deliver in the sprint. A product owner who dictates the sprint scope without team input produces unrealistic commitments that damage velocity, trust, and delivery predictability.
Stories entering sprint planning should already have acceptance criteria, an estimate, and no unresolved questions. A story that needs to be defined during sprint planning is not a story that is ready for a sprint.
Consistently delivering on commitments builds the trust and predictability that allows the business to plan. A team that takes on 100% of theoretical capacity and delivers 70% every sprint is less useful than a team that commits to 85% and delivers it reliably. Velocity is not a productivity target — it is a planning input.
This checklist covers the full sprint planning process in five phases — from pre-meeting preparation through to team commitment and sprint launch.
Sprint planning fails when it attempts to do two jobs at once: refining the backlog and planning the sprint. Refinement should be continuous throughout the preceding sprint, so that the top of the product backlog contains stories that are ready to plan.
A story is ready for sprint planning when all of these are true:
The acceptance criteria are written and testable
The story is estimated in story points
The team has seen this story in a backlog refinement session and has no open questions
Any external dependencies are identified and a plan exists to address them
The story is small enough to complete within one sprint (if not, it is an epic that needs decomposing)
The team understands what “done” looks like
A story that fails any of these criteria entering sprint planning adds risk to the sprint and slows the planning ceremony. The product owner is responsible for the definition of ready — not the team.
Sprint planning that happens slightly differently each sprint — depending on who is facilitating, how much time is available, and how prepared the backlog is — produces inconsistent outcomes. CheckFlow’s recurring sprint planning checklist generates the full preparation and ceremony workflow automatically at the start of every sprint, ensuring the same structured approach is applied every time.
The sprint planning meeting is the last step in the planning process — not the first. CheckFlow’s pre-meeting phase tracks backlog refinement completion, capacity calculation, and dependency identification in the days before the planning session, so the meeting can focus on commitment rather than preparation.
Sprint-over-sprint velocity analysis requires a record of what was committed and what was delivered. Retrospectives require the sprint goal and commitment to be documented. CheckFlow records the sprint goal, committed stories, and capacity calculation for every sprint — automatically, as the planning process runs.
Sprint planning produces the sprint goal and commitment; the sprint review assesses how well the team met that commitment. CheckFlow’s Sprint Review Checklist covers the structured review and retrospective process. See the Sprint Review Checklist →
Features planned in sprints eventually go through the release process to production. CheckFlow’s Feature Release Process Checklist in the Product Development & Launch series covers the technical deployment workflow. See the Feature Release Process Checklist →
A sprint planning checklist covers five phases: pre-meeting preparation (backlog refinement confirmation, story estimates and acceptance criteria verified, capacity calculation, dependency identification, previous retrospective actions reviewed), sprint goal definition (product owner presents a single outcome-oriented goal, team agrees and posts it visibly), story selection (candidate stories reviewed against capacity, unresolved questions deferred, sprint backlog created), task breakdown (stories decomposed into tasks of 1–2 days maximum, initial assignment, within-sprint dependencies identified, definition of done confirmed), and team commitment and sprint launch (team confirms achievability, “70% test” applied, sprint board set up, standup time confirmed).
The Scrum Guide recommends no more than 2 hours of sprint planning per week of sprint length — so 4 hours maximum for a 2-week sprint and 8 hours for a 4-week sprint. In practice, well-prepared teams often complete sprint planning in less time than the maximum. The key determinant is backlog readiness: a team with a well-refined, well-estimated backlog can complete planning in 1–2 hours for a 2-week sprint; a team that needs to refine stories during the planning session will consistently exceed the timebox.
The sprint goal is a single sentence stating the most valuable outcome the sprint should achieve — the “why” of the sprint. It provides coherence to the sprint and gives the team a decision framework for scope trade-offs if problems arise mid-sprint (“does completing this story advance the sprint goal?”). The sprint backlog is the set of product backlog items selected for the sprint plus the tasks required to deliver them — the “what” and “how” of the sprint. The sprint goal is more important than the sprint backlog: a team that achieves the sprint goal with 90% of the sprint backlog completed has had a successful sprint; a team that completes 100% of the sprint backlog but without advancing the sprint goal has delivered work without value.
Velocity is the amount of work (measured in story points) that a team completes per sprint, averaged over the last 3–5 sprints. It is the primary input for capacity planning in sprint planning — a team with an average velocity of 40 story points should not commit to 60 story points in a sprint unless there is a specific reason to believe this sprint is different. Velocity is a planning tool, not a productivity target: teams that are pressured to increase velocity typically respond by inflating story point estimates rather than actually increasing output.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
