Why sprints get overloaded

Sprint planning has one structural failure that templates don't prevent: teams select the sprint backlog before anyone checks capacity. The result is a sprint that looked achievable on a whiteboard and collapses by Wednesday when two engineers are out for half the week, one ticket triples in scope, and three items had unstated dependencies on a service the platform team is rewriting.

The fix is simple and almost never done: commit to capacity before committing to work. The template below opens with a capacity review for exactly that reason.

The agenda (copy-paste this)

Duration: 2 hours for a 2-week sprint; 1 hour for a 1-week sprint
Format: Facilitated, with backlog visible to the full team

Section 1 — Sprint goal (10 min)

One sentence: what does a successful sprint look like from the outside?
The goal should be specific enough that any team member could evaluate at end-of-sprint whether you hit it
Reject goals that are just a list of tickets ("finish the auth refactor and the billing page") — that's a backlog, not a goal

Section 2 — Capacity review (15 min)

List every team member by name
For each: planned PTO, on-call rotation, recurring meetings, known external commitments
Express capacity as available story points or days — not headcount
This number is the ceiling; don't select more work than it supports

Section 3 — Backlog selection (45 min)

Walk highest-priority items from the refined backlog
For each candidate: does the team have enough to start it, or are there open questions that need answers before sprint starts? Open questions belong in the refinement queue, not the sprint
Stop selecting when you hit 80% of capacity; the remaining 20% absorbs spillover and unplanned work

Section 4 — Acceptance criteria (20 min)

For every selected item: state the criterion that makes it done
If the team can't state a criterion in 60 seconds, the ticket isn't refined enough — move it back to the backlog
Write it in the ticket now, in the room; don't rely on "we'll add it later"

Section 5 — Risks and dependencies (15 min)

What could block sprint goal delivery that the team doesn't control?
Name the dependency owner; surface it now while there's time to resolve it before mid-sprint
Unresolved dependencies get a named owner from the team who will track them

Closing (15 min)

Confirm sprint goal is still valid given the selected work
Assign the sprint recap note-taker, or confirm the automated report setup
Confirm next planning date

What most sprint planning templates miss

The most popular sprint planning templates focus on backlog grooming and definition-of-done. Both are important. Neither addresses the planning mistake that produces the most sprint failures: selecting work without checking availability.

A team of five engineers at full capacity has roughly 200 story points available per 2-week sprint. A team of five with two engineers on PTO, one rotating on-call, and one in a three-day offsite has maybe 110. If you select 180 points in the second sprint, you've already failed. The selection step is where the overcommit happens, and capacity has to precede it.

The second gap is acceptance criteria. Teams move fast through planning and intend to write criteria later. Later doesn't happen at the same level of specificity. The person who would have written a precise criterion in the room writes something vaguer from memory the next day, or doesn't write it at all. Mid-sprint disagreements about what "done" means are almost always traceable to skipped acceptance criteria in planning.

The compounding cost of these gaps — overloaded sprints, mid-sprint discoveries, relitigated definitions — shows up clearly when you add it up: The meeting tax.

Why sprint planning notes are harder than they look

Sprint planning generates more information than almost any other recurring meeting: the sprint goal, capacity numbers, item-by-item selection rationale, acceptance criteria per ticket, dependency owners, risk items. Writing a useful recap requires capturing all of it in a form that's useful three days later when someone asks "why did we cut that item?"

Pavleur generates the sprint planning report automatically at the end of the call. It captures the sprint goal, the selected backlog with rationale, acceptance criteria as stated in the meeting, and dependency owners as named. If someone screenshared the backlog or the capacity spreadsheet, that visual is included in the report alongside the discussion — context that audio-only tools like Otter or Fireflies would miss entirely. Anyone who joined late or needs to check a decision mid-sprint has the full record. For a comparison of how this differs from audio-only tools: Pavleur vs. alternatives.

Handling the mid-sprint plan change

The sprint plan is a commitment, not a contract. When something mid-sprint genuinely invalidates the plan — a production incident, a critical dependency blocking three tickets, a priority shift from leadership — the right response is a quick re-planning call, not silent scope drop. The re-planning call takes 20 minutes and produces an updated sprint goal that reflects reality. The alternative is a sprint that fails on paper but informally adjusted in ways nobody wrote down, making the retrospective harder and velocity numbers meaningless.

Build the habit of explicit re-planning. Use the same structure: updated capacity, revised selection, re-stated goal. It takes far less time than the confusion it prevents.