Sprint Planning Template

The template has four sections. The Sprint Goal states, in one or two sentences, why this sprint matters to stakeholders, not a list of tickets. The backlog items section lists what the Product Owner and developers have selected from the product backlog to pursue that goal, refined enough during planning that the team understands each one. The capacity section states what the team can realistically commit to, based on past sprint performance and any known absences or holidays, not an optimistic best case number. The definition of done restates, for this sprint, the shared bar every item must clear before it counts as finished.

A filled in example: Sprint Goal, members can see their certification progress without opening a support ticket to ask. Backlog items, build a progress indicator on the bootcamp dashboard, add a completion percentage to the member profile page, write the microcopy explaining certification requirements. Capacity, 32 story points, based on the team's rolling three sprint average of 34, adjusted down for one developer's planned time off. Definition of done, code reviewed, tested on staging, and confirmed against the certification requirements written in the PRD.

Use this template at the start of every sprint, ideally with the backlog already refined ahead of the meeting so planning focuses on sequencing and capacity rather than discovering scope for the first time in the room. It is not a static document; if the Sprint Goal or the definition of done need to change mid sprint because of new information, both should be updated openly rather than quietly redefined at the retrospective.

Fill in the Sprint Goal first and get the whole team to restate it in their own words before moving to backlog items, since a team that cannot paraphrase the goal will struggle to make good judgment calls about scope later in the sprint. Set capacity from actual historical velocity, not from how much the team wants to prove it can do, since an inflated capacity number just moves the failure from planning into the sprint itself.

The most common mistake is treating sprint planning as a ticket assignment exercise and skipping the Sprint Goal entirely, which leaves the team with no shared answer to why does this sprint matter when priorities shift mid sprint. A second common mistake is setting capacity from an aspirational number rather than the team's actual historical velocity, guaranteeing a pattern of underdelivering against the plan.

Builders Camp's Project Management for Product bootcamp covers this ritual alongside the sprint retrospective template, as part of planning, dependencies, and execution cadence for product delivery. Both templates live in the Builders Camp templates library, included in every Membership alongside the rest of the catalog.