The Sprint Planning Checklist I Use Every Time

Sprint planning meetings have a reputation for being long and unproductive. In my experience, that's usually because the preparation wasn't done. The meeting itself should be relatively short — if you've done the work beforehand.

Here's the checklist I use before every sprint planning session.

Before the meeting

Backlog is groomed. Every ticket going into the sprint should have a clear description, acceptance criteria, and a size estimate. If stories aren't groomed, the planning meeting turns into a refinement session, and you run out of time.

Dependencies are mapped. For every story that depends on another team, confirm the dependency is resolved or has a clear owner. Unresolved dependencies at sprint start are a common source of mid-sprint blockages.

Capacity is calculated. Count up the actual available working days for each team member, accounting for leave, public holidays, and known meetings. Divide by historical velocity to set a realistic sprint goal. Never plan to 100% capacity.

The sprint goal is drafted. Before the meeting, have a proposed sprint goal ready. The team will refine it, but walking in with something concrete moves the conversation forward faster.

During the meeting

Walk through the goal first. Start with "here's what we're trying to achieve this sprint, and why." This gives context before you dive into individual tickets.

Let the team pull work, don't push it. The team should volunteer to take tickets, not be assigned them. This increases ownership and often surfaces risks you wouldn't have spotted top-down.

Surface blockers out loud. At the end, ask: "Is there anything that could prevent us from hitting the sprint goal?" Any answers here become your first risk register items for the sprint.

After the meeting

Send a one-paragraph sprint goal summary to stakeholders before end of day. It should cover what you're building, what you're explicitly not doing, and when you'll demo. Short, clear, and on record.

Sprint planning done well takes maybe 90 minutes for a two-week sprint. If yours is running three hours, the issue is almost always backlog quality or unclear priorities — fix those, and the meeting fixes itself.