#NoEstimates: Is Dropping Story Points the Future of Agile?

“We spent 3 hours estimating and still missed the sprint.”

If that sounds familiar, you’re not alone.
Multiple studies show that software estimates are wrong by 30–50% on average, even in “mature” agile teams. Yet many teams still burn hours arguing whether a story is a 3 or a 5.

So it’s no surprise that the #NoEstimates movement keeps gaining traction.
But is dropping story points the future of agile—or just another fad?

Let’s dig in.

What #NoEstimates Actually Means (And What It Doesn’t)

Before we throw out story points, we need to be precise.

#NoEstimates ≠ No Forecasting

The misunderstood version of #NoEstimates is:

“We don’t estimate anything. We just code and hope for the best.”

That’s not #NoEstimates. That’s chaos.

Serious #NoEstimates practitioners still:

Forecast delivery
Manage scope
Communicate timelines to stakeholders
Track progress and improve predictability

They just don’t rely on upfront story-level estimates to do it.

The Core Idea: Measure Reality, Not Guesswork

Traditional agile estimating assumes:

“If we’re good at estimating, we’ll be good at planning.”

#NoEstimates flips that:

“If we’re good at measuring actual flow, we won’t need to estimate much at all.”

Instead of guessing:

“How many points is this story?”

You focus on:

“How many similar stories do we usually complete per week?”
“How long does work typically take from start to finish?”

Forecasts are based on historical throughput and cycle time, not hours or points.

Why Story Points Are Failing So Many Teams

Story points aren’t inherently bad. The problem is how they’re used in the real world.

1. Estimation Meetings Become a Time Sink

You’ve probably seen this pattern:

10 people in a room for 2 hours
Arguing whether something is a 3 or a 5
Re-estimating when scope changes
Still missing the sprint

That’s 20 person-hours burned on a meeting that:

Didn’t improve delivery
Didn’t reduce risk
Didn’t change the actual work

Multiply that by every sprint, every team, every quarter. It’s a quiet productivity tax.

2. Story Points Get Weaponized

Story points were meant to be relative and team-specific.
But in many organizations, they become:

A performance metric: “Team A delivered 60 points, Team B only 40.”
A comparison tool: “Why are your 5s bigger than their 5s?”
A target: “We need to hit 80 points next sprint.”

Once that happens, estimates stop being honest and start being inflated.
Velocity becomes a game, not a signal.

3. False Precision Creates False Confidence

A roadmap built on story-point estimates often looks precise:

Q1: 300 points
Q2: 350 points
Q3: 400 points

But:

Requirements change
Dependencies appear
People leave, join, or get pulled into production issues

The precision is comforting—but misleading. Leadership thinks:

“We have a plan.”

What they really have is:

“A set of guesses layered on top of other guesses.”

How #NoEstimates Works in Practice

Let’s move from philosophy to mechanics.

Step 1: Slice Work into Small, Consistent Pieces

The smaller and more uniform your stories, the less you need to estimate them individually.

You aim for:

Stories that can be done in 1–2 days by one person
Minimal dependencies
Clear acceptance criteria

Bad example:

“Build user management” → multiple weeks, many unknowns

Better example:

“User can reset password via email”
“Admin can deactivate a user”
“User gets error message when login fails 3 times”

You don’t need to argue whether each is 3 or 5 points. You just need them to be roughly the same order of magnitude.

Step 2: Track Throughput, Not Points

Instead of saying:

“We deliver 40 points per sprint.”

You track:

“We complete 10–12 stories per week.”

This is throughput: how many items you finish in a given time period.

Example:

Over the last 8 weeks, your team:
- Completed between 8 and 13 stories per week
- Median: 10 stories/week

Now when a stakeholder asks:

“When can we ship this set of 50 stories?”

You can say:

At 10 stories/week:
- 50 stories ≈ 5 weeks
With variability (8–13 stories/week):
- 4–6 weeks, with most likely around 5

No estimates. Just math based on actual delivery.

Step 3: Use Cycle Time to Spot Problems Early

Cycle time = how long a story takes from “in progress” to “done.”

Track it over time:

If cycle time is stable, your system is healthy
If it’s creeping up, you’re accumulating:
- Dependencies
- Blockers
- Unplanned work
- Too much WIP (work in progress)

This is far more actionable than debating story points.

Common Mistakes When Teams “Go #NoEstimates”

Dropping story points won’t magically fix a broken process.
Here’s what not to do.

Mistake 1: Removing Estimates Without Improving Flow

If you:

Keep huge stories
Allow constant interruptions
Have unclear priorities
Multitask across 10 things at once

…then removing estimates just removes one of your only feedback signals.

Fix instead:

Enforce WIP limits
Slice work smaller
Clarify priorities each sprint
Protect focus time

Mistake 2: Keeping All the Rituals, Just Without Numbers

Some teams say:

“We’re #NoEstimates now. We still do 2-hour planning poker, we just don’t assign points.”

That’s not #NoEstimates. That’s just less useful estimation.

If you’re not using points:

Shorten planning dramatically
Focus on clarity of scope, not relative sizing
Use quick gut checks: “Is this small enough to do in 1–2 days?”

Mistake 3: Losing All Predictability

Executives still need to know:

“Roughly when will this thing be done?”
“Can we commit to this date for marketing/legal/sales?”

If you say:

“We don’t estimate. We’ll tell you when it’s done.”

You’ll lose trust fast.

Instead, replace:

Story-point based roadmaps

With:

Throughput-based forecasts
Scenario-based conversations:

“If we keep this team stable and don’t add extra scope, we’re 85% confident we’ll finish by mid-September.”

Mistake 4: Ignoring Risk and Uncertainty

Not estimating doesn’t mean ignoring risk.

Risk-aware #NoEstimates teams:

Call out high-uncertainty items explicitly
Spike risky work early
Make trade-offs visible:
- “If we take this experiment on, timeline range widens by 2–3 weeks.”

When Dropping Story Points Makes a Lot of Sense

1. Your Team Is Stable and Mature

If you have:

A stable team (low turnover)
A consistent tech stack
A reasonably clean backlog

Then your historical throughput is a solid predictor.
Story points add more noise than value.

2. Your Stories Are Already Well-Sliced

If most of your tickets:

Are similar in size
Take 1–2 days to complete
Don’t require huge cross-team coordination

Then counting items is enough. You don’t need a layer of abstraction on top.

3. You’re Drowning in Estimation Overhead

If you’re spending:

1.5–2 hours per week per team on estimation
Re-estimating frequently due to shifting scope

You’re likely over-investing in a low-yield activity.
That time is better spent:

Refining requirements
Improving CI/CD
Reducing handoffs

When You Might Want to Keep Story Points (For Now)

Let’s be honest: #NoEstimates is not a silver bullet.

1. Your Stories Are Wildly Inconsistent in Size

If some stories take:

1 day
…and others take:
3 weeks

Then counting “number of stories” is misleading. You either:

Need to learn to slice better, or
Use some kind of relative sizing temporarily

2. You’re in a Highly Regulated or Contract-Heavy Environment

If you’re in:

Government
Defense
Big enterprise with fixed-bid contracts

You may be forced into more formal estimation. In that case:

Use story points, but:
- Keep estimation as light as possible
- Avoid tying points to performance evaluation
- Still track throughput and cycle time

3. You’re Early in Your Agile Journey

If the team is:

New to agile
New to working together
New to the domain

Story points can be a useful teaching tool:

They force conversations about complexity
They reveal misunderstandings early

Just don’t get stuck there forever.

A Practical Path to #NoEstimates (Without Freaking Everyone Out)

You don’t have to flip a switch overnight. Here’s a pragmatic approach.

Step 1: Start Measuring What Actually Happens

For the next 4–6 sprints, track:

Stories completed per sprint (throughput)
Cycle time per story
How much time you spend on estimation

Don’t change anything yet. Just gather data.

Step 2: Experiment with Lighter Estimation

Try for 2–3 sprints:

Only using t-shirt sizes (S/M/L) instead of granular points
Timebox refinement to 30–45 minutes
Asking only:
- “Is this small enough to fit comfortably into a sprint?”
- “What could blow this up?”

See if delivery predictability changes. Spoiler: it usually doesn’t.

Step 3: Run a “No Points” Pilot Sprint

Pick one team and one sprint:

No story points
No planning poker

In planning, focus on:

Clarifying acceptance criteria
Splitting large items
Limiting WIP

Commit to:

A number of stories based on your historical throughput
Example: “We usually do 10–12 stories. Let’s pull in 10 and see.”

At the end of the sprint, compare:

Stress levels
Time spent in meetings
Predictability vs previous sprints

Step 4: Replace Velocity Charts with Throughput and Cycle Time

Instead of showing:

“We did 42 points this sprint.”

Show:

“We finished 11 stories.”
“Median cycle time: 2.1 days.”
“Work in progress stayed under our WIP limit.”

For forecasting, use:

Basic ranges: “This 40-story epic will likely take 4–6 weeks, based on our last 3 months of throughput.”
Simple tools or spreadsheets; you don’t need fancy Monte Carlo from day one.

Step 5: Have Honest Conversations with Stakeholders

Explain to leadership:

Estimates haven’t been accurate anyway
You’re moving to evidence-based forecasting
You’ll provide:
- Ranges, not single dates
- Regular updates based on actual progress

Offer a side-by-side for a while:

“Story-point forecast says: mid-October.”
“Throughput-based forecast says: late September to mid-October.”

Let reality decide which is more trustworthy.

Common Pushbacks (And How to Respond)

“But finance needs estimates for budgeting.”

Fine. Give them epic-level or initiative-level rough sizing:

Use t-shirt sizes or ranges: “This is a 6–10 week effort with a team of 5.”
Revisit and refine as you learn more.

You don’t need story points on every ticket to create a budget.

“Executives want a date.”

Give them:

A range with a confidence level
- “We’re 85% confident this will land between Sept 10–30.”
Clear assumptions:
- “Assuming team remains stable and we don’t add major scope.”

That’s more honest than a single “committed” date based on shaky estimates.

“Developers will just slow down without targets.”

If the only thing driving speed is a points target, you have a culture problem, not a metrics problem.

Use instead:

Lead time
Deployment frequency
Defect rates
Customer outcomes

These are harder to game and more aligned with actual value.

Tools That Make #NoEstimates Easier

You don’t need exotic tooling, but you do need:

A board with clear workflow states
The ability to track cycle time and throughput
Lightweight ways to refine and align

If you still occasionally use planning poker or run retrospectives to improve flow, tools like ScrumPoi help keep those sessions focused and bias-free, especially with anonymous voting and quick, no-signup rooms.

So… Is #NoEstimates the Future of Agile?

If “future of agile” means:

Less time guessing
More time delivering
Forecasts based on reality, not wishful thinking

Then yes, #NoEstimates—or at least “far fewer estimates”—is where many serious teams are headed.

The real shift isn’t “points vs no points.”
It’s this:

From: “We plan by guessing the future.”
To: “We plan by observing how we actually work and improving that system.”

If your team is drowning in estimation meetings, gaming velocity, and still missing dates, it’s time to ask a harder question:

Are story points helping us—or are they just a habit we’re afraid to challenge?

You don’t have to go full #NoEstimates tomorrow.
But you should, at minimum, earn the right to keep story points by proving they add more value than they cost. If they don’t, you know what to do.