Sprint planning is the meeting that sets everything else up. When it goes well, the team walks out knowing exactly what they are building, why it matters, and what done looks like. When it goes badly, you lose two hours and still do not have a clear plan. The gap between the two rarely comes down to process. It comes down to preparation, shared understanding, and knowing when to stop debating and start committing.
A sprint plan is not a commitment to get everything done. It is a shared understanding of what matters most this sprint and a team agreement to go after it together.
Why sprint planning sessions drag
Most sprint planning problems trace back to one root cause: work that was not ready arriving at the session. Stories without acceptance criteria, estimates argued from scratch in the room, dependencies nobody noticed until someone asks. When the team is discovering the work during planning, planning takes forever - and still ends with vague commitments.
The second culprit is an unclear sprint goal. Without a compelling reason why this set of work matters right now, every story becomes a negotiation. Product pushes for more, engineering pushes back on scope, and the session becomes adversarial rather than collaborative. Sprint planning should feel like a team choosing its mission for the next fortnight, not a manager allocating tasks.
Signs planning is broken
Signs planning is working
What needs to be ready before you start
Effective sprint planning is mostly pre-work. The session itself should feel like a confirmation and commitment, not a discovery exercise. Three things must be in place before the team walks into the room.
- A refined backlogThe top of the backlog should contain stories that are understood, estimated, and ordered. If a story will likely be pulled into the sprint, it needs acceptance criteria the whole team has read - not just a title. Backlog refinement sessions throughout the sprint exist precisely so planning does not have to do this work.
- Known capacityBefore committing to a sprint, the team needs to know how much time is actually available. Factor in planned leave, public holidays, and any known commitments outside the sprint. Capacity is not headcount multiplied by sprint length - it is the realistic number of days the team can spend on sprint work.
- A draft sprint goalThe sprint goal answers the question: why does this sprint matter? It should be agreed between the engineering lead and product before the session, not invented during it. A good sprint goal captures the outcome the team is working towards in one sentence. "Complete the checkout redesign so we can start user testing" is a sprint goal. "Implement cards A, B, C, and D" is not.
If any of these three are missing when the session starts, it will run long and end with a weaker plan. It is worth protecting the time to get them right beforehand rather than compensating during planning.
The two-part structure that works
Sprint planning has two distinct jobs. The first is deciding what the team will work on and confirming the sprint goal. The second is figuring out how to do it. Mixing the two is where most sessions fall apart - the team gets pulled into technical detail before the scope is even settled. Keep the two parts separate and complete Part 1 fully before moving on.
- Part 1 - What (30 min)Product presents the sprint goal and walks through the top of the backlog. The team confirms understanding, raises questions, and agrees which stories make the cut. This part ends when the scope is settled and the team has said yes to the sprint goal. Do not move to Part 2 until this is genuinely clear.
- Part 2 - How (time varies)The team breaks down each committed story into tasks, surfaces technical unknowns, identifies blockers, and assigns initial ownership. This is where engineering leads the conversation. Product can step back or leave entirely. The output is a sprint backlog the team has built themselves and believes in.
Sprint planning flow
Committing the right amount
Over-committing is the most common sprint planning mistake. It feels productive to fill the sprint with work. It is not. A team that consistently over-commits builds a habit of carrying work forward, which makes estimation meaningless and retrospectives demoralising. The goal is a sprint the team genuinely believes it can complete.
Velocity - the average number of story points or stories completed per sprint - is a useful guide for how much to pull in. But it is a guide, not a target. Teams that treat velocity as a target to hit or beat create exactly the wrong incentives. Use it to sanity-check the plan, not to fill every slot. A team that consistently finishes clean is healthier than one that consistently ships 90% and carries the rest.
Common over-commitment patterns
Healthier commitment habits
A useful final check at the end of planning: ask the team to rate their confidence in completing the sprint on a scale of one to ten. If the average is below seven, the plan is probably too ambitious. Pull a story out. Finishing a sprint cleanly builds momentum; carrying work forward erodes it sprint after sprint.
Making commitments stick
A sprint commitment means nothing if the team is unclear on what done looks like. The most common reason sprint work spills into the next sprint is not that the team ran out of time - it is that done was defined differently by different people, and nobody caught it until the last day.
Before closing the planning session, confirm three things for each story in the sprint. First, the acceptance criteria are agreed by both engineering and product. Second, any known blockers have an owner and a plan to resolve them. Third, the engineer picking up the story has enough context to start without needing a separate briefing. These three checks prevent most sprint failures.
Story readiness check
Actions created during planning - blocked dependencies, technical investigations, things that need external input - should be captured and assigned before the session ends. If they are not written down with a clear owner, they will not happen. Keeping actions connected to context is what stops sprint planning creating more noise than clarity.
Your role as manager in sprint planning
The manager's job in sprint planning is to protect the team's ability to commit credibly. That means pushing back when the backlog is not ready, making sure capacity is accurate, and ensuring the sprint goal is clear before the session starts. It does not mean filling the sprint or negotiating scope on the team's behalf.
During the session, your role is mostly facilitation: keeping Part 1 and Part 2 separate, stopping rabbit holes, surfacing decisions that need to be made, and making sure the session ends with a plan the team actually owns. If you find yourself directing the technical conversation in Part 2, you are probably over-involved. Let the team lead that part.
- Before the sessionConfirm the backlog is refined and the sprint goal is agreed. Check capacity for the sprint period. Brief the product manager on what is realistically achievable so there are no surprises in the room.
- During Part 1Facilitate the sprint goal conversation. Help the team say no to stories that are not ready. Keep the discussion on whether the scope is right, not on the technical detail of how it will be built.
- During Part 2Create space for the team to plan their own work. Surface blockers as they come up and make sure each one is assigned. Note any actions the team creates so they do not get lost.
- At the closeCheck the team's confidence level in the plan. Summarise what was committed and why. Confirm who owns outstanding blockers. Note any carry-over risks before the first stand-up of the sprint.
Frequently asked questions
Keep sprint actions on track
Capture actions from planning, connect them to context, and never lose track of what was agreed. Free to start.