Sprint planning used to eat three hours of everyone's time. Engineers, designer, me - all in a room, going through tickets one by one, discovering mid-meeting that the acceptance criteria were missing, writing them on the spot, realizing we needed to talk to another team first, parking the ticket, moving on. By the end we'd committed to a sprint that nobody actually believed in.
I've gotten it down to 45 minutes. Here's what I changed and why it works.
3 hours. Acceptance criteria written on the spot. Dependencies discovered mid-meeting. Sprint commitment nobody believes in.
45 minutes. Tickets pre-reviewed. Engineers read async. Meeting is sequencing and commitment, not discovery.
Why estimation theater happens
The core problem is that sprint planning tries to do two incompatible things at once: clarify requirements and plan the sprint. These require completely different mental modes. Clarification is exploratory - you're figuring out what you don't know. Planning is committal - you're deciding what you'll do. Mixing them means you're constantly switching between "wait, what does this ticket even mean?" and "okay, how long will it take?"
But there's a deeper reason estimation goes wrong: engineers are estimating things they don't fully understand yet. When a ticket says "add payment method management," that sounds like a two-day task. Then someone asks "does this need to handle the case where a user has a pending transaction on the card they're trying to remove?" and suddenly you're looking at a week of work involving transaction locks, async job queues, and a bunch of edge cases around eventual consistency in the payment state machine. The estimate was wrong not because the engineer was bad at estimating - it was wrong because the ticket was underspecified.
At Uzum, we process enough orders that these edge cases aren't theoretical. A race condition in payment method removal that affects 0.01% of users is still hundreds of users a day. Engineers who've worked at scale know this, so they hedge their estimates. That hedging looks like sandbagging to PMs who don't understand why.
The prep work is the actual meeting
I do all the clarification work the day before planning. Every ticket going into the sprint gets reviewed by me. If acceptance criteria are missing, I write them. If there's a dependency on another service or team, I flag it explicitly in the ticket - not buried in a comment, in the description. If a ticket touches a shared database table or a third-party API with rate limits, I note that too, because those are the things that blow up mid-sprint.
By the time we're in the planning meeting, engineers have already read the tickets. They've had time to think asynchronously, which is how engineers actually think best. The meeting isn't discovery - it's sequencing and commitment.
The specific things I look for during prep: hidden dependencies between tickets (two tickets that both modify the same table schema will conflict), third-party API constraints (if we're integrating with a payment provider that has a sandbox environment with different behavior than production, that needs to be in the ticket), and async work that's easy to underestimate (draining a job queue before a migration, backfilling data, anything that runs as a background process and can't be easily rolled back).
What I ask instead of "how many points?"
I stopped fighting about story points. Not because they're useless - relative complexity estimation is genuinely valuable - but because the way most teams use them, the conversation becomes a negotiation between the PM who wants more in the sprint and engineers who want less. That's not estimation, it's politics.
Instead I ask: "Is there anything in this sprint you're worried about?" That question surfaces the real risks. The ticket with an unclear dependency on the notification service. The feature that requires a database migration on a table with 50 million rows - which means we need a zero-downtime migration strategy, not just an ALTER TABLE. The integration with a third-party API that has a 100 requests-per-minute rate limit that we'll definitely hit during load testing.
Story points don't tell you about any of that. "Are you worried about anything?" does.
When engineers flag concerns, we address them before committing. Sometimes that means pulling a ticket. Sometimes it means breaking it into a migration ticket and a feature ticket. Sometimes it means accepting the uncertainty and explicitly building in a buffer day. The point is we're talking about real risks, not arguing about whether something is a 5 or an 8.
The commitment question
At the end of planning I ask: "Are you comfortable with this sprint?" Not "can you commit to this?" - that's a loaded question engineers feel pressure to answer yes to regardless of how they actually feel.
"Are you comfortable?" is different. It invites honest answers. If someone's not comfortable, I want to know why before we start, not on day 8 when we're already behind.
The goal is a sprint the team actually believes in. A sprint that's 20% too ambitious and everyone knows it produces stress, partial completion, and a demoralized team at the end. A sprint that's slightly conservative and everyone commits to produces momentum and a team that trusts the process. I'll take the second one every time.
What I gave up is the illusion of precision. Sprints don't always end with every ticket done - sometimes a ticket reveals complexity that wasn't visible during planning, and that's fine. Software estimation is hard because software is the act of building something that's never been built before. What I gained is a team that comes to planning without dread and generally ships what it commits to. That's worth more than three hours of theater.