by Gary Worthington, More Than Monkeys

Let’s settle this up front

the primary reason agile teams estimate work is to clarify scope, not to produce timelines

Yes, I said it.

Estimation is not a mystical ritual that if performed correctly, spits out a reliable delivery date. And it’s definitely not a measure of team performance. It’s a tool (one of many) to help us talk about complexity, uncover gaps, and reduce risk before we build the wrong thing.

Somewhere along the way though, teams and stakeholders got the wrong end of the stick. Story points became hours. Velocity became commitment. Estimation became performance management.

And so teams started gaming the system. Inflating estimates. Treating velocity like a KPI. Obsessing over whether something’s a 3 or a 5 like it actually matters.

It’s time that we hit the reset button.

Estimation Is a Thinking Tool, Not a Forecasting Tool

Here’s what good estimation gives you:

• A conversation about what you think the work involves
• A way to spot differing assumptions within the team
• A signal that something might need to be broken down
• A shared understanding of complexity, risk, and unknowns

That’s it. That’s the job.

If you’re using Planning Poker, T-shirt sizing, or any other relative estimation approach, the real value isn’t in the number you land on; it’s in the discussion it sparks.

If the estimate changed after you talked about it, great. That means the estimate did its job.

Forecasting? That’s a Different Kettle of Fish

Want to know when something will be done?

Use a forecast.

Based on real data.

Not a guess that stakeholders will take as a promis.

There are better tools for that job. Tools that use what you’ve actually delivered to make evidence-based predictions. The three most useful ones?

1. Throughput: How Much We Deliver

Throughput is simple: how many work items (stories, tickets, bugs, whatever) a team completes in a given time period.

Let’s say your team finishes 10 tickets per week on average. If there are 50 stories in the backlog, a rough forecast might suggest you’ll be done in around 5 weeks.

It’s not perfect as not everything is the same size, but if your stories are relatively consistent in complexity, throughput becomes a fast, cheap proxy for delivery pace. This is one of the reasons to keep stories small and of a similar size.

And the best part? You don’t need story points. Just count the things you finish.

2. Cycle Time: How Long Work Takes

Cycle time measures how long a single piece of work takes to go from “in progress” to “done”.

If your average cycle time is 3 days per story, and you’ve got 10 stories left, then all things being equal, you’re looking at roughly 30 days to finish the lot.

But here’s where it gets more interesting: by tracking cycle time across many stories, you build up a distribution. You might see that 50% of stories finish in 3 days, but 85% finish within 5. That’s useful for managing expectations especially with stakeholders who want “confidence levels” on delivery.

3. Probabilistic Forecasting: When Will It Be Done?

Instead of saying, “We’ll definitely be done by 15 July,” probabilistic forecasting says, “There’s an 85% chance we’ll be done by 15 July based on how we usually perform.”

This is where things like Monte Carlo simulations come in. You feed in your past throughput or cycle time data, tell the tool how much work remains, and it runs thousands of simulations to give you a probability range.

So instead of promising a deadline you can’t confidently meet, you can have a grown-up conversation about risk, confidence, and trade-offs.

Stakeholders love this, by the way because it gives them options. “We could aim for 15 July with 85% confidence, or go for 1 July with only 50%. Your call.”

And yet again, you don’t need story points to do this. You just need consistent units of work and decent historical data.

Stop Using Estimation for Things It Wasn’t Designed For

Estimation is brilliant at:

✅ Surfacing unknowns
✅ Creating shared understanding
✅ Getting everyone on the same page before delivery

Estimation is terrible at:

❌ Predicting exact timelines
❌ Driving delivery accountability
❌ Being treated as a commitment mechanism

If you’re estimating to figure out “when it’ll be done,” you’re using the wrong tool. Use forecasting instead.

If you’re estimating to understand what the hell a story actually involves, you’re doing it right.

TL;DR — Estimation ≠ Forecasting

• Estimation is for understanding work
• Forecasting is for predicting timelines
• One is a conversation, the other is a calculation
• Use both, but for everyone’s sanity, don’t confuse them

Gary Worthington is a software engineer, delivery consultant, and agile coach who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups build products that work, scale, and deliver value fast. Whether it’s aligning teams, modernising delivery practices, or validating product ideas, he helps turn chaos into clarity.

Follow Gary on LinkedIn for practical insights into agile delivery, engineering culture, and building software teams that thrive.