Here's a radical idea: what if you stopped estimating entirely?
No story points. No t shirt sizes. No planning poker. No arguing whether something is a 3 or a 5.
Just pick the most important thing and start working.
Sounds reckless, right? But a growing number of teams are doing exactly this. And they're shipping faster, not slower.
What We'd Lose
Let's be honest about what estimation provides:
1. Capacity planning: Knowing how much you can commit to in a sprint.
2. Prioritization: Understanding the cost/benefit of different options.
3. Predictability: Giving stakeholders a sense of when things will be done.
These aren't trivial concerns. So what happens without estimates?
What We'd Gain
1. Time back
Sprint planning takes hours. Planning poker. Debates about complexity. Refinement sessions.
All that time goes away. Instead, you spend 15 minutes deciding what's most important and get to work.
2. Less attachment to the plan
When you've estimated a sprint's worth of work, you feel committed to it. Even if priorities change halfway through, you're reluctant to drop things because "we planned for this."
Without estimates, you're more nimble. Work on what matters today, not what mattered three days ago when you planned the sprint.
3. Focus on value, not velocity
Story points turn into a game. Teams optimize for closing points, not delivering value. "Let's pick these three 5 point stories instead of that one uncertain 8 pointer."
Without points, you can't play that game. You have to actually think about what creates value.
How It Works
Teams that skip estimation rely on different mechanisms:
Small tasks: Break work down until everything is roughly similar in size. If everything takes 1-3 days, you don't need to estimate. You just count.
Continuous prioritization: Instead of planning a sprint, you maintain a prioritized backlog. Always work on the top item. When it's done, grab the next one.
Cycle time tracking: Instead of velocity, track how long tasks actually take from start to finish. This gives you a realistic sense of throughput without estimates.
Transparent progress: Stakeholders see working software frequently. They don't need estimates because they can see what's done and what's next.
The Hard Part
The biggest challenge isn't internal. It's external.
Stakeholders want dates. Bosses want commitments. Sales wants to promise features to prospects.
Without estimates, you can't give them the certainty they crave. The best you can offer is:
"Here's what we're working on. Here's what we think is next. We'll keep you updated every week."
For some organizations, that's not acceptable. They need the theater of estimation, even if the estimates are wrong.
But for others, honesty is refreshing. "We don't know exactly when it'll be done, but we're working on the most important thing right now" is more truthful than "we'll ship in 6 weeks" when you have no idea if that's true.
When It Makes Sense
No estimates work best for:
- Small, cross functional teams
- Products with flexibility on timelines
- Organizations that value agility over predictability
- Teams that can keep tasks small and well defined
It's harder for:
- Large organizations with fixed release schedules
- Regulated industries with compliance deadlines
- Distributed teams with complex coordination
- Projects with hard external dependencies
The Experiment
You don't have to commit forever. Try it for a sprint:
- Break work into small, similar sized tasks
- Prioritize the backlog
- Work on the top item until it's done
- Move to the next item
- Track how much you actually ship
Compare that to a typical sprint with full estimation. Did you ship more? Less? About the same?
Most teams find they ship about the same amount, but with less overhead and more flexibility.
The Real Question
Estimation isn't inherently bad. But it's worth asking: are we estimating because it helps, or because we've always done it?
If your estimates are consistently wrong, if planning sessions feel like a waste, if you're optimizing for velocity instead of value, maybe it's time to try something different.
You might find that the thing you thought was essential... wasn't.