Vact Sprint Planning Checklist: Prepare, Run, and Follow Up
Sprint planning is the ceremony that determines what the team will build in the next sprint and how they will approach the work. A well-prepared sprint planning session takes 60-90 minutes and produces a clear sprint goal, a committed backlog, and shared understanding of the work. A poorly-prepared session takes three hours and produces confusion. The difference is preparation.
Sprint Planning Checklist: Prepare, Run, and Follow Up
This checklist covers everything the Product Owner, Scrum Master, and development team need to do before, during, and after sprint planning to make it efficient and effective.
Before Sprint Planning (2-3 days prior)
Product Owner Prep
- Groom the top backlog items. The top 15-20 items in the backlog should have clear descriptions, acceptance criteria, and design assets or specs linked. Items without acceptance criteria are not ready for sprint planning.
- Draft the sprint goal. Propose a sprint goal that aligns with the current product priorities and roadmap. The goal should articulate what value this sprint delivers, not what tasks will be completed.
- Identify dependencies. Flag any items that depend on external teams, vendors, or blockers that must be resolved before the team can start. See dependency management for tracking approaches.
- Prepare context. Be ready to explain the “why” behind each item. Developers who understand the user problem make better implementation decisions than developers who only see acceptance criteria.
Scrum Master / PM Prep
- Close the current sprint. Review the sprint board. Move incomplete items back to the backlog (or carry forward per team agreement). Update status of all remaining items.
- Pull sprint metrics. Velocity from the last 3-5 sprints. Sprint completion rate. Carryover items. These numbers inform capacity planning.
- Review retrospective action items. Are there process changes from the last retrospective that affect how this sprint should be planned? (e.g., “reduce sprint scope by 10% to account for unplanned work”)
- Check team capacity. Who is on PTO, in training, or partially allocated to other work? Calculate available capacity in story points or hours based on actual availability.
- Book the room / send calendar invite. Ensure the meeting is on everyone’s calendar with the correct video link and any pre-read materials linked in the description.
Development Team Prep
- Review top backlog items. Read the descriptions and acceptance criteria for the top 15 items before the meeting. Note questions and concerns to raise during planning.
- Complete carryover work. If possible, finish any in-progress items before the new sprint begins. A clean board at sprint start prevents carryover from consuming capacity in the new sprint.
- Identify technical considerations. Flag items that need architectural discussion, have technical risks, or require spike work before estimation.
During Sprint Planning (60-90 minutes)
Part 1: The What (30 minutes)
| Step | Activity | Time |
|---|---|---|
| 1 | Scrum Master reviews last sprint results: velocity, goal achievement, carryover | 5 min |
| 2 | Product Owner presents proposed sprint goal and explains business context | 5 min |
| 3 | Team discusses and refines the sprint goal until alignment | 5 min |
| 4 | Product Owner walks through top backlog items in priority order | 15 min |
During the backlog walkthrough, the team asks clarifying questions. The Product Owner explains acceptance criteria, user context, and priority rationale. Items that are not clear enough are sent back for refinement.
Part 2: The How (30-45 minutes)
| Step | Activity | Time |
|---|---|---|
| 5 | Team estimates items using the agreed method (story points, T-shirt sizes, or hours) | 15 min |
| 6 | Team pulls items from the backlog into the sprint until capacity is reached | 10 min |
| 7 | Team identifies sub-tasks, assigns initial owners, and flags dependencies | 10 min |
| 8 | Final commitment: “Can we achieve the sprint goal with this scope?“ | 5 min |
The team — not the Product Owner, not the PM — decides how much work fits in the sprint. The PO sets priority; the team sets capacity. This distinction is fundamental to Scrum.
Part 3: Confirmation (5 minutes)
- Sprint goal stated and agreed
- Sprint backlog committed
- Dependencies identified and owners assigned
- Team members know their starting tasks for day one
After Sprint Planning (within 24 hours)
Scrum Master / PM
- Update the sprint board. Ensure all committed items are in the sprint with correct status, assignee, and estimates.
- Document the sprint goal. Post it in the project Slack channel, on the sprint board description, and in the team wiki.
- Communicate to stakeholders. Send a brief message to stakeholders summarizing the sprint goal and key deliverables expected. This sets expectations for the sprint review.
- Schedule the sprint review and retrospective. If not already recurring, book these for the last day of the sprint.
Development Team
- Break committed items into sub-tasks if not done during planning. Each sub-task should be completable within 1-2 days.
- Start work. Begin with the highest-priority items that support the sprint goal. Do not wait for a separate kick-off — sprint start is the kick-off.
Capacity Planning Formula
A simple capacity model for sprint planning:
- Count available team days. If the sprint is 10 business days and the team has 5 members, the theoretical maximum is 50 person-days.
- Subtract absences. PTO, training, meetings outside the team. If two members each have 1 day off, subtract 2 days: 48 person-days.
- Apply focus factor. Teams typically spend 60-70% of their time on sprint work (the rest is meetings, support, and unplanned items). At 65%, 48 days becomes 31 productive person-days.
- Convert to story points. If the team’s historical velocity is 30 story points in a 10-day sprint with full capacity, adjust proportionally.
The historical velocity from the last 3-5 sprints is the most reliable capacity indicator. Use it as the primary guide and adjust for known capacity changes.
Common Sprint Planning Mistakes
Over-committing. Teams that commit to 40 points when their average velocity is 28 set themselves up for failure. Use data, not optimism, for commitment.
Ungroomed backlog. If the Product Owner has not groomed the top items, the team spends planning time asking basic questions instead of estimating and committing. Grooming should happen before planning, not during.
No sprint goal. Committing to a list of stories without a unifying goal means the team has no basis for making tradeoff decisions mid-sprint. See sprint goal setting for how to write effective goals.
Ignoring carry-over. Pretending incomplete work from the last sprint does not affect capacity is a recipe for perpetual over-commitment. Account for carry-over items in the capacity calculation.
A sprint planning session that follows this checklist runs smoothly, respects everyone’s time, and produces a commitment the team can deliver with confidence. The work invested in preparation pays for itself many times over during the sprint.