The #NoEstimates debate: when story points help and when they hurt

Two groups of developers in a friendly standoff, one side holding estimation cards and the other side holding flow charts and cycle time graphs, with a divide between them Story points have been the default unit of agile estimation for over two decades. Then Woody Zuill tweeted #NoEstimates in 2012, and the argument hasn't stopped since. The #NoEstimates camp says estimation is waste. The pro-estimation camp says you can't plan without it. Both sides have valid points, and both overstate their case. Here's what actually holds up when you look past the Twitter debates.

What #NoEstimates actually argues

The movement gets misrepresented often. Woody Zuill, Vasco Duarte, and other advocates aren't saying "never estimate anything ever." Their core argument is more specific:

• Most estimation effort doesn't produce decisions that are better than what you'd get from simpler methods
• Story points get misused as commitments, deadlines, and performance metrics
• Teams spend hours in estimation sessions that could be spent building software
• Historical throughput data (how many items you finish per sprint) predicts delivery dates more reliably than summing up story points

Duarte's book #NoEstimates makes a data-driven case: if you track how many stories your team completes each sprint and those stories are roughly the same size, you can forecast delivery dates using Monte Carlo simulations without ever assigning a point value. The argument isn't anti-planning. It's that story points are an expensive way to get information you can get cheaper.

Where #NoEstimates has a point

Some of the criticism lands.

Story points drift into performance metrics

This is the most common failure mode. A manager sees Team A delivering 40 points per sprint and Team B delivering 25, and concludes Team A is more productive. So Team B starts inflating their estimates. Within a few sprints, story points measure nothing except how much pressure the team feels. The Scrum Guide explicitly warns against this, but it happens constantly. Once points become a target, they stop being useful as an estimation tool.

Estimation sessions eat real time

A team of seven developers spending two hours estimating 20 backlog items costs 14 person-hours. If those estimates don't change any decisions, that's 14 hours of waste. For teams with stable backlogs and predictable work, the estimation ceremony can become exactly that: a ceremony.

False precision kills good judgment

Debating whether something is a 5 or an 8 for twenty minutes is a real thing that happens in real sprint plannings. The Fibonacci sequence was supposed to prevent this by forcing jumps between numbers, but teams still agonize over it. That time would be better spent breaking the story into smaller pieces. Developer looking at a whiteboard covered in estimation numbers and question marks, scratching their head in confusion while teammates debate in the background

Where #NoEstimates falls apart

The movement also has blind spots.

It assumes small, uniform stories

The "just count stories" approach only works when stories are roughly the same size. Duarte acknowledges this and recommends breaking everything down until items are small enough to be interchangeable. That's good practice, but it's also a form of estimation. You're implicitly saying "this is small enough to be a 1" every time you split a story. You've just replaced explicit estimation with implicit estimation. Teams working on varied work — infrastructure one week, frontend features the next, third-party integrations after that — can't pretend all stories are equal.

New teams need calibration

A team that's been together for two years can often skip estimation because they have shared mental models. They know roughly what's involved in building a new API endpoint or redesigning a page. A team that formed last month doesn't have that. Story points, and more importantly the discussions around them, build shared understanding fast. When one developer estimates a 3 and another estimates a 13, the conversation that follows is where the team actually learns about the work. Throughput data can't teach your team that the senior dev assumed you'd use the existing API while the junior dev assumed you'd build a new one.

Stakeholders need forecasts

Product managers, sales teams, and executives don't care about story points. But they do need to know: "Will feature X ship before the conference in April?" Throughput-based forecasting can answer that question. So can velocity-based forecasting using story points. The #NoEstimates camp has a viable alternative here, but it requires historical data that many teams don't have, especially early in a project or after significant team changes.

When story points earn their keep

There are situations where estimation pays for itself: Early-stage teams. The structured conversations from planning poker build shared understanding fast. The estimates themselves matter less than the disagreements they surface. Mixed-complexity backlogs. When your backlog includes "change a button color" next to "migrate the payment system," counting stories without sizing them produces garbage forecasts. Cross-team coordination. Multiple teams feeding into a shared roadmap need a common sizing language so product managers can make tradeoff decisions. Spotting scope creep. Stable velocity but missed commitments? The gap between estimated and actual points tells you stories are growing after they enter the sprint. Team gathered around a table with planning poker cards laid out, some cards showing matching numbers and others showing wildly different values, sparking animated discussion

When to skip story points

Story points become overhead in other contexts: Mature teams with stable throughput. If your team has been together for 18+ months and finishes a consistent number of similarly-sized stories per sprint, throughput data already tells you what you need. Kanban-style flow. Teams using continuous flow rather than sprints get more from tracking cycle time (how long items take from start to finish) than from upfront estimation. Spikes and research tasks. Estimating exploratory work is guessing about guessing. Timebox it instead: "We'll spend two days investigating this and report what we found." Maintenance and support work. Bug fixes and operational tasks are reactive. Tracking throughput makes more sense than estimating each ticket individually.

The middle ground most teams actually need

The useful answer isn't "always estimate" or "never estimate." It's to match your approach to your context.

Context	Approach
New team, complex product	Planning poker with story points. The conversation matters more than the numbers.
Established team, varied work	Lightweight estimation (T-shirt sizing or quick planning poker). Keep it fast.
Established team, uniform work	Track throughput. Skip estimation.
Cross-team roadmap planning	Use story points or T-shirt sizes for high-level forecasting.
Support/maintenance	Track cycle time and throughput. Don't estimate individual tickets.

Most teams land somewhere in the middle: they estimate the stories that need it and skip estimation for routine work. That's fine. The goal was never to have a perfect system. The goal is to make good enough decisions about what to build and when it'll be done.

What both sides get right

The #NoEstimates movement forced a useful question: "Are we getting value from this estimation session, or just going through the motions?" Every team should ask that regularly. The pro-estimation camp is right that structured discussion about upcoming work prevents surprises. Planning poker works not because the numbers are accurate, but because the conversations surface hidden complexity before it becomes a mid-sprint problem. The winning approach borrows from both: estimate when it generates useful discussion or improves forecasting accuracy. Stop when it becomes ritual. If your team uses planning poker, Kollabe supports quick estimation sessions that keep the focus on discussion, not ceremony. And if you're tracking throughput instead, that works too. Use what gives you better forecasts and fewer mid-sprint surprises. Last Updated on 10/02/2026