Most sprint planning meetings fail for the same reason: the team arrives to decide what to do when it should arrive to confirm what it already understands. This is the 45-minute format we use for our own product sprints, and the setup work that makes it possible.
Why planning drags
If planning regularly runs past an hour, one of three things is happening:
- Stories are still being written in the meeting. Acceptance criteria get invented on the spot and everyone estimates a different feature.
- Nobody owns the goal. Without a sprint goal, every backlog item is equally important, so the discussion is about ordering instead of outcomes.
- Capacity is a guess. Leave, meetings and support rotation are remembered mid-meeting, and the plan gets rebuilt twice.
Before the meeting: 20 minutes of refinement
Planning is only fast when refinement happened earlier in the week. The product owner does three things:
- Writes one sprint goal in a single sentence. If it needs an "and", it is two goals.
- Marks the top 10 to 12 backlog items ready: clear description, acceptance criteria, an estimate, and no open questions.
- Records capacity: who is out, who is on support, and how many focus days that leaves.
In Kydero this lives on the backlog page. Ready items carry a story-point estimate and a linked goal, so the planning view already shows how much of the goal the top of the backlog covers.
The 45-minute agenda
1. Goal and capacity (5 minutes)
The product owner reads the goal. The Scrum master states the capacity. No discussion yet, only clarifying questions.
2. Pull, don't push (25 minutes)
Developers pull ready items into the sprint one at a time and say out loud how each one serves the goal. If someone cannot explain the link, the item stays in the backlog. The velocity chart from the last three sprints is on screen, so the team stops when the committed points reach the historical range.
The plan is done when the team can say what "done" looks like on the last day, not when the backlog is empty.
3. Risks and dependencies (10 minutes)
Walk the committed items once more and mark blockers: an API that another team owns, a design that is not final, a data migration that needs a maintenance window. Each risk gets an owner and a date, and Kydero shows it as a dependency on the board so it is visible during the daily.
4. Confirm (5 minutes)
The Scrum master reads back the goal, the commitment and the risks. Everyone says yes or names the one thing that would make them say no.
What changes after three sprints
- Planning ends on time because the arguments moved to refinement, where they belong.
- Commitment accuracy improves. Teams that use a velocity range instead of a single number hit their sprint goal far more often.
- Mid-sprint scope changes become visible. A new item has to displace something tied to the goal, which is a conversation with the product owner rather than a quiet addition.
A checklist you can copy
- One sentence sprint goal, written before the meeting.
- Top 10 to 12 items marked ready with estimates.
- Capacity recorded, including support rotation.
- Velocity chart for the last three sprints on screen.
- Items pulled by developers, each linked to the goal.
- Risks listed with owners and dates.
- Read-back and explicit yes from everyone.
Run it twice and the meeting starts to feel short. That is the point: planning should be the calm part of the sprint, not the loud one.