Sprint Planning: A No-BS Guide for Product Managers

Most sprint planning meetings are an exercise in shared misery.

You sit in a room (or on a Zoom call) for two hours, painfully reading off Jira tickets one by one, while engineers quietly look at their phones or work on a side branch. Everyone makes up arbitrary story points, you agree to a list that is roughly 30% too ambitious, and then two weeks later, you push everything that didn't get done into the next sprint.

It is a broken ritual. It doesn't have to be.

The Pre-Work is the Work

If you are figuring out what to build inside the sprint planning meeting, you have already failed.

The meeting is for alignment and capacity checking, not discovery.

Before the meeting starts, the PM should have a tightly prioritized list of tickets. Every ticket needs acceptance criteria that can be tested by a human, and it needs to be small enough to be completed inside the sprint window. If a ticket just says "Refactor the backend pipeline," you are doing it wrong.

Micro-list for pre-sprint readiness:

• Clear goals set.
• Ambiguity removed from top tickets.
• Dependencies identified.
• The backlog is actually groomed.

Capacity is Not Velocity

Stop treating your engineers like servers with exactly 40 hours of uptime a week.

Your velocity from the last sprint is a historical artifact, not a guarantee. You have to factor in the physics of human teams. People get sick. Production goes down. Unplanned hotfixes happen.

When planning, assume max capacity is 70%. The other 30% is for the friction of reality. If you stuff the sprint to 100% of theoretical capacity, any minor speed bump will cause the entire sprint to derail.

The "One Goal" Rule

Every sprint needs a singular narrative. What is the one sentence we can tell the rest of the company when this sprint is over?

"We are shipping the new onboarding flow." "We are stabilizing the payment infrastructure."

If your sprint looks like a random assortment of disconnected bugs and minor feature tweaks, the team will lose momentum. Context switching is expensive. Grouping work by a cohesive theme gives the team a focal point. It turns a list of tasks into a mission.

Sizing and Estimation Fake-Outs

Estimation in product management is mostly just corporate astrology. Story points, t-shirt sizes, hours—none of it is objectively accurate.

But you still need to do it. Why? Because the discussion about the estimate is where the value is.

If Engineer A thinks a ticket is a 2, and Engineer B thinks it's an 8, you don't compromise at 5. You have them talk. Usually, Engineer B knows about a legacy system dependency that Engineer A missed. The point isn't predicting the future; the point is uncovering hidden complexity before the work starts.

Reminder: You Are Not The Boss of the Code

Your job is the "What" and the "Why." The engineers own the "How" and the "How Long."

If an engineer says a task takes three days, you do not negotiate it down to two. You can negotiate the scope (can we remove this feature to make it take two days?), but you never negotiate their time estimate. The second you do that, you destroy trust.

Keep it tight. Keep it honest. Ship the work.

---

FAQ

How long should sprint planning actually take?

If you have done the pre-work correctly, a two-week sprint planning meeting should take 45 minutes to an hour. Anything over an hour means you are either debating requirements (which should have been done in grooming) or your team is too large.

Should we include bugs in the sprint?

Yes. Dedicate a consistent percentage of every sprint (e.g., 20%) to tech debt and bugs. Do not treat bugs as secondary citizens; if they are affecting users, they are product work.

What do we do when a sprint inevitably fails?

You hold a blameless retro. Do not punish the team. Look at the system. Did you overcommit? Did an external dependency block you? Find the systemic flaw, adjust your capacity downward for the next sprint, and move on.