Iteration Planning

Iteration planning is where commitment meets reality. It's the ceremony where the team looks at what's ready, what's realistic, and what they're willing to commit to for the next one to two weeks.

Done well, it produces a shared plan the whole team believes in. Done poorly, it's a status meeting with extra steps -- or worse, a negotiation where leadership assigns work and the team quietly disagrees.

What makes a good planning meeting

A good iteration planning meeting has three qualities:

1. The backlog is ready. Stories at the top of the queue have clear acceptance criteria. The team isn't seeing them for the first time.
2. The team commits, not the PM. The people doing the work decide what's realistic. The PM brings context about priority, not mandates about scope.
3. It ends with a plan, not a wish list. Everyone leaves knowing what they're working on, what "done" means in outcome terms, and what they'll demo at the end of the iteration.

Before the meeting

Preparation is where most planning meetings succeed or fail. A PM who walks in with a clean, prioritized backlog gets a focused 45-minute meeting. A PM who walks in with a messy backlog gets a two-hour debate.

Backlog triage (do this 1-2 days before):

• Move anything stale or unclear out of the top 10. If a story has been sitting for three iterations, it either needs rewriting or deprioritizing.
• Confirm the top stories have acceptance criteria written in concrete terms. "User can do X" is concrete. "Improve the experience" is not.
• Flag dependencies. If Story A can't start until Story B is done, make that explicit.
• Talk to engineering before the meeting about anything technically risky. Surprises in planning meetings create drag.

Running the meeting

Time: 30-60 minutes for a one-week iteration; 45-90 minutes for two weeks.

1. Reflect on last iteration (5-10 min)

Quick review: what did we commit to, what did we ship, what carried over? This isn't a retro -- it's calibration. If the team committed to 8 stories and shipped 5, that's data for today's commitment. (If this pattern persists, you may need a delivery diagnostic.)

2. Set context (5 min)

The PM shares what's most important this iteration and why. Not a feature list -- a priority frame. "Our goal this iteration is to get the onboarding flow shippable so we can start the beta next week" gives the team a lens for making tradeoffs.

3. Walk the stories (15-30 min)

Go through each candidate story, top to bottom:

• PM explains the "what" and "why"
• Design clarifies interaction details or open questions
• Engineering asks clarifying questions and flags complexity
• Team estimates (if you estimate) -- t-shirt sizes or points, whichever your team uses

Stop when you hit the team's capacity. Don't negotiate to "fit one more in." Over-commitment is the single most common planning failure.

4. Commit (5 min)

The team agrees on what they're taking on. This is a real commitment, not a suggestion. If something doesn't get done, the team should understand why -- and it should feed back into the next planning meeting.

Common failure patterns

Pattern	What it looks like	Fix
Over-commitment	Team commits to more than they can finish, every iteration	Use last iteration's actual velocity as the ceiling, not the aspiration
Vague stories	Stories grow mid-iteration because criteria weren't clear	Require acceptance criteria before a story enters planning
PM as dictator	PM assigns work; team doesn't push back	Explicitly ask: "Does this feel realistic? What would you cut?"
No reflection	Team doesn't look at what happened last iteration	Start every planning meeting with the numbers: committed vs. completed
Surprise complexity	Engineering discovers mid-iteration that a story is much harder than expected	Pre-flight technically risky stories with engineering before the meeting

Try this today

If your planning meetings feel like they're not working, try one change: start with last iteration's numbers. How many stories did you commit to? How many shipped? What carried over? That five-minute calibration transforms the rest of the meeting because it grounds the conversation in reality instead of optimism.