Sprint planning

Sprint planning is the single most leveraged 90 minutes in a software team's week. Done well, the team commits to a realistic scope they'll actually finish — and the rest of the sprint runs on autopilot. Done badly, you spend two weeks discovering the plan was fiction.

Most teams have a sprint planning meeting. Fewer have a sprint planning practice. This hub is the practice — five focused articles on the parts of sprint planning that change outcomes:

• Capacity planning that survives reality — naive capacity is team size × sprint days. Realistic capacity is 50-65% of that. Why, and what to do about it.
• Story sizing without flame wars — Fibonacci vs t-shirt sizes, when to estimate, when to stop, and how AI helps without taking over the room.
• Sprint goals worth committing to — the difference between "complete these 12 stories" and "deliver the multi-tenant CSV export." Goals teams care about.
• Retrospectives that change behavior — formats that work, formats that don't, and the role of AI in surfacing patterns from sprint data.
• Burndown charts and what they actually tell you — the false-positive trap, what to track alongside burndown, what to ignore.

Why we wrote this

We see ~5,000 sprints a quarter run through Stride. The patterns are stark: the teams that ship the most aren't the ones with the most discipline-theatre. They're the ones who treat sprint planning as a real practice — explicit capacity math, opinions about story sizing, clear sprint goals, retros with consequences, and metrics that don't lie.

The articles below are opinionated. Where we recommend something, it's because we've seen ~100 teams do it the other way and watched them struggle. Where we say "either works," it's because we've seen both succeed.

What sprint planning is for

Three jobs. Get all three right, the rest takes care of itself.

1. Convergence on scope. Engineering, product, and design align on what's actually going into this sprint. Disagreements surface here, not on day 8.

2. Surfacing risk. The story that's going to take 3x the estimate is identified before the team commits. AI is great at flagging risk; humans are better at deciding what to do about it.

3. Building shared mental model. Everyone leaves with the same picture of what success looks like. When friction arises mid-sprint, the team can resolve it against that shared picture instead of relitigating.

Planning meetings that don't do these three things are theatre. Drop them or fix them.

How AI changes the practice

AI doesn't replace sprint planning — it changes which 30 minutes of the meeting are valuable.

The arithmetic part (capacity math, point estimates, dependency lookup) takes the AI seconds. The judgment part (which stories matter, what's the real scope, who can take what given last week's chaos) is what humans should spend the meeting on.

Teams that adopt AI sprint planning report 60% less time in planning meetings — not because they cut corners, but because the AI does the boring 60% before the meeting starts and the humans use the saved time on the parts that need their attention.

Read in order, or jump in

The articles work independently — read whichever one matches the pain you're feeling now. If you're starting fresh on a new team, read in order; capacity → sizing → goals → burndown → retros is the natural arc of a sprint cycle.