I run Kollabe, a free planning poker tool. We've got around 70,000 users using it every month. And I keep getting the same question from people outside the agile world: why are developers still doing this?
It's a fair question. We have AI that can estimate tickets now. We have historical data. We have tools that can look at a codebase and make educated guesses about complexity. So why are smart people still sitting in a virtual room holding up cards with numbers on them?
I've talked to a lot our users users about this. The answer aligned pretty well with my own experiences.
The number isn't the point
Here's what most people get wrong: nobody actually cares if a ticket is a 3 or a 5. The velocity math works out either way over time.
What matters is what happens when someone votes 3 and someone else votes 8.
That gap is where the value lives. Because now you have a conversation. "Wait, you think this is an 8? What am I missing?" And then someone mentions the legacy payment system this ticket touches. Or the API that's being deprecated next month. Or the fact that QA is going to need three days with this one because of some edge cases the ticket doesn't mention.
That information was locked in someone's head. The vote forced it out.
AI can't fix this
I get pitched constantly on AI estimation features. "Let us analyze your tickets and predict story points." And look, we've built some AI stuff into Kollabe. It's useful for certain things.
But AI can't tell you that your tech lead gets twitchy every time someone mentions the auth module. It doesn't know that the DevOps guy is on vacation next week and he's the only one who understands the deployment pipeline for that service. It hasn't been in the meeting where someone said "we'll clean that up later" two years ago and never did.
Your team has context. They have history. They have opinions about what's actually going to happen when this code hits production. Planning poker is just a structured way to get that stuff out of their heads.
What actually surfaces in these conversations
I've asked a lot of teams what they learn during estimation that they didn't know going in. Same themes keep coming up:
Dependencies nobody wrote down. "Oh, that needs the inventory team's API? They're doing a migration right now."
Scope that seemed obvious but wasn't. "Does user authentication include the SSO flow, or just email and password?"
Landmines in the codebase. Someone who's been around a while will just know that a particular file is fragile, or that a certain pattern has caused problems before.
Experience gaps. Sometimes a junior dev will vote low because they found a simpler approach. Sometimes they'll vote low because they don't know what they don't know. Either way, you want to find out before day three of the sprint.
The ritual matters too
There's something else going on here. Planning poker is a ritual, and rituals have value.
It's dedicated time where everyone focuses on the same thing. It creates a weird kind of psychological safety because you're not arguing with your lead directly - you're just revealing a card. You can disagree without it feeling like a confrontation.
For remote teams especially, these synchronous moments matter. It's easy to lose shared understanding when everyone's async all the time.
So yeah, it's 2026
Teams are still playing planning poker. They'll probably still be playing it in 2030.
Not because the story points are magic. Not because we haven't invented something better. But because the conversation that happens when two people disagree about a number is genuinely useful, and we haven't found a way to automate that.
The point was never to get the estimate right. The point was to have the conversation that helps you avoid getting it catastrophically wrong.
Top comments (2)
This pretty much sums up my experience as well
I’ve been lucky enough to work with teams that all get along really well and usually enjoy our infrequent rituals. Planning poker has always been really good for discussions