The worst sprint planning meeting I ever sat through ran for three hours and ended with nobody able to say what we were actually building that week. Fourteen people, a backlog projected on a wall, and a product manager reading tickets aloud one by one while engineers checked Slack. By the end we had "committed" to forty-one story points, a number that meant precisely nothing, and two of those tickets turned out to depend on a vendor integration that wasn't going to be ready for a month.
I inherited that ritual when I took over the payments platform team, and killing the bad version of it while keeping the useful core took me the better part of a year. Sprint planning is one of those meetings everyone claims to hate and nobody wants to cancel, because the alternative — engineers picking up whatever feels interesting on Monday morning — is worse. So the question isn't whether to do it. It's how to run it so the people in the room stop rolling their eyes.
Respect Is Earned in the First Ten Minutes
Engineers decide whether a meeting is worth their attention almost immediately, and once they've checked out you don't get them back. The fastest way to lose them is to walk in unprepared and start doing prep work in front of everyone. If the backlog isn't groomed, if acceptance criteria are missing, if nobody knows whether the design is signed off — you are now paying fourteen salaries to watch two people argue about what a ticket means.
The fix is boring and it works: the backlog gets refined before planning, not during it. On my teams the tech lead and the product manager spend forty-five minutes the day before making sure the top fifteen items are ready — clear description, acceptance criteria, no obvious open questions, dependencies flagged. Then planning itself becomes a decision meeting, not a discovery meeting. When people can tell you did the homework, they extend you the benefit of the doubt on everything else.
The Goal Comes Before the Tickets
Here is the single change that improved my planning sessions more than anything else, and it cost nothing. Before we look at a single ticket, we agree on one sentence: what is this sprint for? Not a list of tasks — an outcome. "Merchants can save a payout method and reuse it." "We cut the settlement job from ninety minutes to under twenty." One clear goal that a reasonable person could later look at and say yes, we did that, or no, we didn't.
Without that sentence, sprint planning degenerates into a shopping trip. You fill the cart until it feels full and then you leave. With it, every ticket has to justify its presence against the goal, and the ones that don't earn their spot are easy to defer. It also gives the team something to protect. When a stakeholder shows up on Wednesday with an urgent request, "that doesn't serve this sprint's goal, let's talk about next sprint" is a far stronger answer than "we're kind of busy."
Estimation Is a Conversation, Not a Number
I've watched teams spend twenty minutes arguing whether something is a three or a five, as if the difference carried the fate of the company. It doesn't. The number is almost never the point. The disagreement is the point. When one engineer says two and another says eight, they are not bad at math — they are looking at different pictures of the work, and one of them knows something the other doesn't.
So when estimates diverge, I don't push for consensus on the number. I ask the outliers to explain. Nine times out of ten the person who estimated high has spotted a landmine: a database migration nobody accounted for, a piece of legacy code that will fight back, a compliance review that has to happen before anything ships. That five-minute conversation is worth more than the estimate itself. The number is just the thing that forces the conversation to happen.
The value of estimation isn't the estimate. It's that two people who assumed they understood the same work discover, out loud and before they start, that they didn't.
Capacity Is a Fact, Not an Aspiration
Every overloaded sprint I've seen was planned by someone doing arithmetic on a fantasy. They took the team's headcount, multiplied by the number of working days, and treated that as available capacity. Then reality arrived: someone was on call, someone had a day of interviews, two people had a compliance training that ate an afternoon, and the on-call engineer spent Tuesday chasing a production alert instead of writing features.
Real capacity is smaller than you want it to be, and pretending otherwise doesn't make the work go faster — it just moves the disappointment to Friday. I ask the team to subtract the known drains before we commit to anything:
- On-call and production support — usually one full engineer's worth of time, gone.
- Holidays, planned leave, and the half-days that vanish into all-hands and reviews.
- Interview loops and onboarding, which are real work even when they don't feel like it.
- A buffer for the unplanned, because in a regulated payments shop something will break and it will be urgent.
When I started planning to roughly seventy percent of theoretical capacity, our completion rate went from missing the sprint most weeks to hitting it most weeks. The team wasn't working harder. We just stopped lying to ourselves about how much actually fits in the box.
The Commitment Belongs to the Team
There is a particular flavor of planning meeting where the manager assigns the work and the engineers nod, and everyone leaves technically agreed and privately resentful. I've done this. Early in my management career I thought a decisive leader filled the sprint himself. What I actually did was strip the team of ownership and then wonder why they didn't care when things slipped.
Commitment has to come from the people doing the work, which means they have to be able to say no, or "not like that," or "not this much." If the team can't push back on scope in the room, then it isn't planning, it's dictation with extra steps. My job in that meeting is to hold the goal and the constraints steady — this is what matters, this is roughly what we have — and then let the engineers decide how much of it is honest to promise. A commitment they made is one they'll defend. A commitment I imposed is one they'll quietly abandon the first time it gets hard.
Dependencies Are Where Plans Go to Die
The tickets that wreck a sprint are almost never the hard ones. The hard ones are visible; people respect them and plan around them. The killers are the small tasks with an invisible string attached — the two-point ticket that quietly needs a config change from the platform team, or sign-off from risk, or a feature flag someone else controls.
In payments this is constant, because so little of what we ship is entirely ours to ship. A refund flow touches the ledger, the notification service, a partner bank's API, and a compliance checklist. So during planning I make dependency-hunting an explicit step: for each committed item, who or what outside this room has to do something before it's done? If the answer isn't "nobody," that item carries risk, and it either gets its dependency confirmed before we commit or it gets a fallback plan. I once watched a team miss a quarter's headline feature because one approval sat in someone else's inbox for three weeks and nobody had flagged it as a blocker until it already was one.
Keep It Short and Guard the Clock
A two-week sprint does not need a four-hour plan. If planning is dragging, it's a symptom — usually of unrefined backlog or unclear priorities — and the answer is to fix the input, not to schedule more meeting. My planning sessions run about ninety minutes for a two-week sprint, and I'd rather end early than fill the slot.
The discipline that makes this possible is refusing to solve engineering problems in the room. The moment two people start whiteboarding an actual design, I stop them: take it offline, you two, and report back. Fourteen people do not need to watch a technical debate that concerns three of them. Protecting everyone else's time is a form of respect, and people notice when their leader treats an hour of the team's collective attention as the expensive thing it is.
Planning Is Only as Good as the Retro
Planning and retrospective are the same loop viewed from two ends. If you consistently commit to twelve things and finish seven, your planning is broken, and no amount of exhortation to "focus" will fix it — the numbers are telling you your estimates or your capacity model are wrong. The retro is where you actually get better at planning, provided you're willing to look at the gap honestly instead of blaming the sprint for the plan's optimism.
I keep a simple running record: what we committed, what we finished, and the one biggest reason for any miss. Over a few months the patterns are obvious. Maybe you always underestimate anything touching the ledger. Maybe on-call load is worse than you modeled. Maybe a particular kind of ticket is never as ready as it looked. That record turns planning from guesswork into something that compounds — each sprint slightly less wrong than the last.
Conclusion
The teams that respect their own planning aren't the ones with the fanciest tools or the tidiest board. They're the ones where the meeting reliably produces a plan that survives contact with the week. That reliability is the whole game — respect follows competence, not the other way around. If you want engineers to take planning seriously, make it a meeting where serious things get decided and honest limits get named, then get out of the way. Do that for a quarter and you'll notice something quiet and good: people stop treating sprint planning as a tax on their week and start treating it as the thing that keeps the week from running them.