Planning is where the team decides what to work on next. The output is a backlog that’s ordered, estimated, and ready to be picked up. If the team leaves planning confused about what they’re building or why, the session failed.
When you need this#
- Engineers frequently ask “what should I work on next?” because the backlog is unclear or unordered.
- The team over-commits and consistently carries work over from one iteration to the next.
- Priorities shift mid-iteration without the team knowing, and people find out their work was deprioritized after they’ve already started.
- Tickets land in “In Progress” that nobody remembers agreeing to work on.
When to run it#
Once per iteration, at the start. For most teams that means weekly or biweekly. The cadence matters less than the consistency. Pick a rhythm and protect it.
Who should be there?#
The team lead, the engineers, and ideally someone from product or the stakeholder side. Product’s job is to answer “why does this matter?” and “what does success look like?” Engineering’s job is to answer “how complex is this?” and “what’s the approach?”
If product can’t attend, the team lead needs to represent their priorities accurately. Don’t guess. If you’re not sure what product wants, find out before planning starts.
Know who the decision maker is#
Planning is a collaborative conversation, not a vote. Everyone should have input, but everyone should also know who makes the final call when there’s a disagreement.
Designing by committee is one of the fastest ways to grind a planning session to a halt. You’ll see it happen: two people have strong but different opinions on priority or approach, and the group goes back and forth for 20 minutes without resolving it. That’s a sign that nobody knows who breaks the tie.
Before planning starts, make it explicit. Usually it’s the team lead for technical decisions and product for priority decisions. The names matter less than the clarity. If the team knows “when we can’t agree on scope, Sarah decides” and “when we can’t agree on approach, Marcus decides,” disagreements resolve in seconds instead of derailing the session.
This also improves outcomes. When a single person is accountable for a decision, they feel the weight of it. They listen more carefully, think it through, and own the result. When a decision is made “by the group,” nobody owns it, which means nobody feels responsible when it turns out to be wrong, and nobody is motivated to course-correct.
The format#
1. Review last iteration#
Start by looking at what got done and what didn’t. This isn’t a blame session. It’s a calibration exercise. If the team consistently over-commits, that’s a planning problem, not a performance problem.
Questions to ask:
- Did we hit the goal we set last time?
- What carried over, and why?
- Were there any surprises that threw off the plan?
Carryover tickets go back into the backlog. Don’t assume they’re still the top priority just because they were started. Re-evaluate them alongside everything else.
2. Set the goal for this iteration#
One sentence. What is the team trying to accomplish by the end of this iteration? “Ship the login flow” is a goal. “Work on a bunch of tickets” is not.
The goal gives the team a filter for every decision they make during the iteration. When someone asks “should I pick up this unrelated bug?”, the answer is “does it help us hit the goal?” If not, it can wait.
3. Walk through the candidates#
Pull tickets from the top of the backlog (and scan the icebox for anything newly relevant). For each ticket:
- Does everyone understand the problem? If not, clarify it now. Don’t send people off to build something they don’t understand.
- Are the acceptance criteria clear? An engineer should be able to read the ticket and start working without a follow-up conversation.
- Is this the right size? If a ticket feels like it’ll take more than a few days, it probably needs to be broken down. (See From Problem to Feature: Scoping Work for guidance on this.)
4. Estimate#
If your team uses estimation, this is where it happens. See the Estimating page for the mechanics of how to run a pointing session.
Not every team needs formal estimates. If your team can reliably commit to a set of work and deliver it, you can skip this step entirely. Estimation is a tool for setting expectations, not a ceremony you owe to the agile gods.
5. Commit#
The team agrees on the set of tickets for this iteration. This is a commitment, not a wish list. If you’re not confident the team can finish everything, cut scope now. It’s much better to finish 5 tickets than to start 8 and finish 4.
Common problems#
Planning takes forever. If your planning sessions run over an hour for a small team, you’re probably refining tickets during planning instead of before it. Tickets should arrive at planning mostly ready. Use a separate backlog refinement session (even async) to get them into shape ahead of time.
The team over-commits every iteration. This is the most common planning failure. People are optimistic. They forget about meetings, code reviews, production incidents, and the fact that someone is taking Friday off. Build in slack. If the team has 8 days of capacity, plan for 6 days of work.
Nobody pushes back on priorities. If the team accepts every ticket without discussion, they’re either not engaged or they don’t feel like they have permission to challenge scope. The team lead should actively invite pushback: “Is this really more important than X?” or “Are we sure we need all of these acceptance criteria?”