Before the Meeting

Sprint planning fails when it starts cold. Before the meeting: (1) Product owner refines and prioritizes the backlog, (2) Stories have clear acceptance criteria, (3) Technical questions are pre-answered in comments, (4) Team knows their capacity (vacations, on-call, meetings). The planning meeting should be about commitment, not discovery. If stories need extensive discussion, they're not ready — move them to backlog refinement.

Estimation Techniques

Story points: Relative complexity (1, 2, 3, 5, 8, 13). Compare new stories to reference stories your team has completed. T-shirt sizing: S/M/L/XL for rough planning. No estimates: Count stories instead of sizing them — works when stories are consistently small. Planning poker: Each person votes independently, discuss outliers. The goal isn't precise estimates — it's shared understanding of scope. If estimates vary wildly, the story isn't well understood.

Capacity Planning

Total available days × 0.7 = sprint capacity. The 30% buffer accounts for: code reviews (10%), meetings and Slack (10%), bugs and unplanned work (10%). If your team has 5 engineers for a 2-week sprint: 5 × 10 days × 0.7 = 35 productive days. Track actual capacity over time — some teams are closer to 60%, others to 80%. Don't fill sprints to 100% — that's a recipe for constant failure and burnout.

Breaking Down Work

No task should take more than 3 days. If it does, decompose it: (1) Separate backend and frontend work, (2) Split into API endpoint + database migration + UI component, (3) Extract research/spike as a separate task, (4) Identify dependencies and parallelize. Smaller tasks provide better progress visibility, earlier code reviews, and faster feedback. A 2-week story that's "80% done" on day 9 is usually 50% done.

Making Sprint Commitments

The team commits to what they believe they can complete — not what management wants. Pull from the top of the prioritized backlog until capacity is reached. Leave 1-2 stories as stretch goals. Every committed story should have: clear acceptance criteria, no blocking dependencies, and an assigned owner. If the team can't commit to a product-critical story, surface the blocker immediately — don't hide it in optimistic estimates.

Common Sprint Planning Mistakes

Over-committing: Planning to 100% capacity ensures failure. Vague stories: "Improve search" is not a story — "Add autocomplete suggestions to search bar" is. Ignoring tech debt: Reserve 15-20% for maintenance. Not accounting for reviews: Every PR needs 1-2 reviewers' time. Skipping retrospectives: Without retros, you repeat the same mistakes. Long planning meetings: If planning takes more than 2 hours, your backlog isn't refined enough.

Measuring Sprint Health

Velocity: Points completed per sprint — track trends, not absolute numbers. Completion rate: % of committed stories finished — aim for 80%+. Carry-over: Stories that spill into the next sprint — should be rare. Cycle time: Time from "in progress" to "done" — shorter is better. Use these metrics for team improvement, never for individual performance evaluation. A team that consistently delivers 30 points is healthier than one that swings between 50 and 10.