Sprint planning used to make me anxious. I'd walk in with a long list of things I wanted done, engineering would estimate them, and we'd spend two hours negotiating what fit. Everyone left a bit unhappy.
What fixed it wasn't a new template. It was doing more of the thinking before the meeting, so the meeting could focus on what only the whole team could decide together.
What the PM should bring
The Scrum Guide describes sprint planning as answering why the sprint is valuable, what can be done, and how it will get done. 1 The product manager owns most of the "why" and a lot of the "what."
Before the meeting I try to have:
- A proposed sprint goal. One or two sentences on what this sprint should achieve.
- A ranked list, with the top items clearly ready to start.
- Stories with acceptance criteria for the top items. I wrote about writing those separately.
- Known constraints. Holidays, a release freeze, a partner dependency, someone on call.
- Open questions I couldn't answer alone, flagged in advance.
If the top items aren't ready, the meeting turns into backlog refinement. Refinement is useful too, just a different meeting.
Set a goal, not just a list
A sprint goal gives the team a way to make decisions when things change mid-sprint. "Finish tickets 101 to 115" doesn't. "Users on Android TV can resume playback from the home screen" does.
When something unexpected comes up, the team can ask whether it helps or hurts the goal. Without one, every change is a negotiation.
Be honest about capacity
| What reduces capacity | Often forgotten? |
|---|---|
| Holidays and leave | Sometimes |
| On-call or support rotation | Often |
| Meetings and reviews | Often |
| Bug fixes from the last release | Very often |
| Unplanned requests from leadership | Almost always |
I've found it helps to leave a deliberate buffer for the things that always happen but never get planned. If the buffer isn't needed, pull something in later. That feels much better than dropping something at the end.
Let the team own the "how"
Once the goal and priorities are clear, I try to step back. The engineers decide how to break down the work and how much they can take on. If they say something is bigger than I thought, I'd rather hear it now than discover it on day eight.
If the estimate surprises me, I ask what's driving it. Sometimes there's a smaller version that gets most of the value. That's where a product manager can really help in the planning conversation, by offering a cut in scope rather than pushing for more.
Don't overcommit to please anyone
There's always pressure to fit more in. A stakeholder needs something, leadership wants to see progress, and it feels easier to say yes in the meeting.
But a sprint that's overloaded from the start usually ends with half-finished work and a team that stops trusting the plan. I'd rather commit to less and finish it. If you want to feel how quickly capacity runs out, Sprint Rush is a small game on my portfolio built around exactly that pressure. It's simplified, but the lesson carries over.
After the meeting
Write down the goal and the committed items where everyone can see them. Share it with stakeholders who care, along with what didn't make it and roughly when it might.
That last part saves a lot of follow-up questions. People handle "not this sprint" much better when they hear it early and with a reason.