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.

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.

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.

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.

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.

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.