Sprint Planning Checklist

The product manager walks the top 15-20 stories in the backlog and confirms each has acceptance criteria, a linked design (if applicable), and no blocking open questions. Stories that aren't ready don't enter planning — better to plan a smaller sprint than to commit to underspecified work.

Definition of Ready typically requires: clear acceptance criteria, sized (story-pointed), no unresolved dependencies on other teams, and design assets attached for UI work. The tech lead reviews each candidate story against the team's posted DoR.

Identify stories that depend on platform, design, or external API work owned by another team. Confirm in writing (Slack thread or Jira link) that the dependency will be ready by the sprint date — verbal commitments slip.

Subtract PTO, holidays, on-call rotations, and known meetings from each engineer's working hours. Account for the standard ceremony overhead (standups, retro, planning itself). Capacity-per-person rarely exceeds 65-70% of nominal hours.

One sentence describing the outcome, not the output — e.g., "Customers can self-serve API key rotation" rather than "Ship the key-rotation endpoint." The goal should still hold even if individual stories get cut mid-sprint.

Walk the goal at the start of planning. Ask each engineer to paraphrase it back — if anyone reframes it differently, that's a signal the wording is ambiguous and needs another pass.

Link the sprint goal in Jira to the parent epic or quarterly OKR. Sprints disconnected from the roadmap are a warning sign — surface to the PM and engineering manager before committing.

For each candidate story, the assigned engineer drafts subtasks: schema migration, API endpoint, frontend wiring, tests, feature-flag plumbing. Tasks under a day each. Stories that won't decompose under 3 days of work usually need to be split, not estimated harder.

Use Fibonacci (1, 2, 3, 5, 8, 13). Anything an engineer estimates at 13+ should be split before commitment — large stories are where sprints derail. Tools: Linear's built-in estimation, or a simple Slack poll.

Stories with unresolved technical uncertainty (new third-party API, untested library, schema change touching a hot table) become time-boxed spikes — usually 1-2 days. Don't estimate the implementation until the spike resolves.

Create a spike ticket with a clear exit criterion ("Decide whether to use Stripe Connect or build custom payouts; produce a one-page recommendation"). Time-box to 2 days max. The spike's output replaces the original story estimate.

Common risks: pending design review, infra capacity, on-call load, holiday gaps, third-party API rate limits, untested DB migration on a large table. The Scrum Master captures these in the sprint Confluence page or Linear cycle notes.

Every risk gets one named owner and a one-line mitigation. "DB migration on the events table — owner: Priya — mitigation: run in batches with replication-lag monitoring, dry-run in staging on Day 2." Unowned risks are how sprints fail quietly.

Subtract the on-call engineer's planned capacity by 30-50% depending on alert volume. Teams that plan on-call at 100% capacity are the same teams that miss sprint commitments every cycle a SEV2 fires.

The team selects sized stories that ladder up to the sprint goal until the running total approaches capacity. Goal-aligned stories first, then maintenance and tech-debt items in remaining capacity.

Compare sum of committed story points to the capacity captured in backlog refinement. If the team is consistently committing above its trailing 3-sprint velocity, the goal is too ambitious — cut scope now rather than mid-sprint.

Drop the lowest-priority story or split a large one in half. Document what was cut and why in the sprint notes — repeated cuts in the same area are a signal that estimation or definition-of-ready is breaking down.

Each engineer states aloud (or types in the planning channel) that they're committed to the sprint scope. Silent agreement is a common source of mid-sprint surprises.

Start the cycle, set the end date, and ensure all committed tickets are assigned to engineers. Mid-sprint additions should require explicit Scrum Master approval — drift is the #1 cause of missed sprint goals.

Sprint goal, scope summary, key risks, on-call engineer, and link to the cycle in Jira/Linear. Stakeholders outside the team rely on this for visibility — skip it and you'll get pinged for status all sprint.

Verify staging is on the latest main, feature-flag service is reachable, and any new third-party sandbox credentials are provisioned. Engineers blocked on environment setup on Day 1 lose a disproportionate share of sprint capacity.

30-minute checkpoint roughly halfway through the sprint to review burn-down, surface blockers, and decide whether to cut scope. Earlier than the retro, narrower than a standup.