Sprint Planning

Purpose: Align the team on goals, capacity, and the specific work committed to for the upcoming sprint

How to run this meeting

Sprint planning only works if the backlog is groomed before you walk in the room. Refinement is a separate meeting — if you arrive at sprint planning with unestimated tickets or stories that haven't been discussed, you'll spend the first half of the session doing work that should have been done earlier. The product manager and tech lead should align on the top 1.5x worth of backlog items before the session starts.

Use story points or t-shirt sizes consistently. The specific scale matters less than using it consistently over time, because the value comes from your team's historical velocity — not from the numbers themselves. When estimating, ask "how complex is this relative to a story we've done before?" not "how many hours will this take?" The latter invites false precision; the former builds calibration.

Reserve roughly 20% of sprint capacity for tech debt, bug fixes, and unplanned work. Teams that pack sprints to 100% of capacity consistently miss commitments because reality is unpredictable. If the sprint ends with capacity to spare, pull in the next item from the backlog. Don't treat the sprint plan as a contract — treat it as a forecast.

Before the meeting

• Groom and estimate the top backlog items (at least 1.5x sprint capacity worth)
• Confirm team availability and calculate actual capacity for the sprint
• Review the previous sprint's velocity to calibrate estimates
• Identify any known interruptions (on-call rotations, holidays, planned leave)
• Draft 1–3 sprint goal candidates for discussion with the team
• Carry over any incomplete items from the last sprint and re-estimate if needed

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 60–90 minutes for a 2-week sprint

---

Sprint Goals

The 1–3 outcomes that define success for this sprint. Goals should be specific and testable — not a list of features.

Proposed goals:

1. Users can complete a checkout flow end-to-end without manual intervention
2. API response times on the search endpoint fall below 200ms p95
3. (stretch) Admin panel supports bulk user export

Agreed sprint goal: Ship end-to-end checkout and hit the search latency target. Bulk export is stretch if capacity allows.

---

Capacity

Actual available capacity after accounting for leave, on-call, and other known commitments. Be honest here — padding leads to sandbagging.

• Last sprint velocity: 58 pts
• Target this sprint: 55 pts (leaving ~14% buffer for unplanned work)

---

Candidate Backlog Items

Items considered for the sprint, ordered by priority. Mark what's committed vs. stretch.

---

Estimation Notes

Record any stories where the estimate was debated, revised, or where important context emerged.

• #1138 (search optimization) was initially estimated at 8 but bumped to 13 after @dev flagged that the query rewrite requires touching three separate services and a schema migration.
• #1155 (bulk export) was deferred from last sprint — re-estimated at 13 (was 8) because the data volume requirements have grown.
• #1162 (flaky CI) is deliberately included as tech debt allocation — team agreed not to defer it again.

---

Risks

What could threaten the sprint commitments? Identify now so you can monitor during the sprint.

• Search optimization (#1138) has a DB schema migration — if staging validation takes longer than expected, it could push to next sprint.
• @dev's on-call rotation mid-sprint is unpredictable; #1138 is assigned to @dev and has the most complexity.
• No QA resource this sprint — the team will need to self-test more carefully, especially on checkout (#1160).

---

Final Sprint Backlog

The confirmed commitment. This list should not change during the sprint without an explicit conversation.

---

Owners

Who is responsible for what outside the ticket-level assignments.

• Sprint goal accountability: @product-lead
• Blocker escalation: @tech-lead
• Sprint demo coordination: @maya (this rotation)

---

Action Items

Follow-up

The sprint board should be updated and visible to the team before EOD on planning day. The sprint goal should be posted in the team Slack channel so everyone has a shared north star. Mid-sprint check-in (typically Wednesday of week two) should review progress against the goal — not just ticket completion. The sprint demo is the accountability moment; every committed item should be demonstrable.