Quick apology up front: there’s some bad language in this post. I’m not trying to be edgy. I’m trying to accurately reflect how it feels to sit through yet another meeting where adults roleplay certainty with Fibonacci numbers.

I fucking hate estimating work.

Not because I’m allergic to planning. Not because I think teams should just “wing it”. I hate it because I’ve spent years watching good engineers and decent product people get dragged into estimation theatre, then judged on how well they acted.

And recently, the absolute sack of shit I’ve seen being pushed as “best practice” for story point estimation has been enough to make me want to throw up.

Story points, done well, are a simple tool. Done badly, they are a slow-motion car crash that somehow gets put on a KPI dashboard and called “delivery”.

Let’s talk about what story points were meant to be, what we turned them into, and how to get back to something resembling sanity.

What story points were supposed to be

Story points were meant to be relative sizing.

Not time or effort. Not “how many days until Dave misses his kid’s parents evening”.

Relative sizing- A way for a team to compare pieces of work and say:

• this feels bigger than that
• this has more unknowns and risk
• this crosses more boundaries (systems, people, approvals)
• this looks small but has a history of biting us

Points are not truth. They are a prompt for conversation inside a team that shares context.

Used properly, points help a team make trade-offs without pretending they can see the future. They are deliberately fuzzy because the work is fuzzy.

That’s the whole fucking point.

What story points have become

In too many organisations, story points have been turned into a cursed blend of:

• a promise
• a budget
• a performance target
• a management comfort blanket
• a stick to hit teams with

Points are treated like a currency, and velocity like GDP. We all know it’s a flawed metric, but it is printed in big numbers and it makes spreadsheets happy, so we keep worshipping it.

This is where it goes wrong.

Converting points to time

“OK so one point is roughly a day.”

No. It isn’t.

The moment you convert points to hours or days, you have reinvented time estimation, but with extra steps and more arguments. Now you still have all the pain of hours-based estimates, plus you get to spend an hour debating whether something is a 3 or a 5 like it is a meaningful scientific question.

If you want hours, use hours. If you want points, stop pretending they are hours. Pick one and own it.

Treating velocity as a target

“We need to increase velocity.”

This is the agile equivalent of telling a football team to “score more goals” while refusing to discuss tactics, fitness, injuries, or the fact that you sold the striker.

Velocity is an output of how a team works in a specific context. It is not a knob you turn. If you target it, you get exactly what you deserve:

• point inflation
• gaming
• corners cut
• quality problems
• teams avoiding risky work because it is “bad for velocity”

Then you wonder why you are shipping more points and less value.

Points as individual performance

If you are tracking story points per person, stop it. Seriously, just stop.

Story points were created as a team-level planning aid. Turning them into an individual score is how you guarantee people will optimise for personal output over team outcomes. You will get heroics, firefighting, and local optimisation. You will not get sustainable delivery.

Also, if you do this, you are telling your best collaborators to leave. They will, and they should.

Estimation meetings that eat delivery

Some teams spend more time estimating work than doing it.

They do planning poker like it is a sacred rite. They argue the difference between a 5 and an 8 while the actual work sits untouched. They re-estimate stories mid-sprint, then “carry over points” like it is accounting.

And in the middle of it all is the unspoken truth: everyone knows the numbers will be wrong, but we act as if the ritual is what makes it valid.

It is not. It is just theatre with stickies.

The real reason this keeps happening

Because someone somewhere wants certainty in an uncertain world.

A date, A fixed scope, A plan that can be communicated upwards with confidence. So the team is pressured to convert uncertainty into a single number that looks official.

The thing is, software is not assembly-line work. It is knowledge work. Discovery is part of the job. Risk is part of the job. Integration is part of the job. “It worked on my machine” is practically a feature.

So when an organisation demands certainty, story points become a way to pretend certainty exists. Everyone gets to feel better for a week, until reality arrives and ruins the sprint plan. Again.

No one expects the Spanish Inquisition, but everyone expects the estimate.

When Copilot starts assigning story points unprompted, you know we’ve properly lost the plot

Recently, during a session to improve the comprehension on a Jira ticket, GitHub Copilot told me the ticket was “5 points”.

100% Unsolicited.

No request, No prompt, No “do you want help sizing this?”. Just a confident little drive-by estimate, like a bloke in a pub telling you how England could have played Scholes and Gerrard in the same midfield 4.

With zero knowledge, Zero context and Zero reference stories. No understanding of our codebase, architecture, team, definition of done, release process, test strategy, or the fact that the last “small change” in that area triggered a week of incident calls and quiet swearing.

So I questioned it, and Copilot apologised and told me how absolutely right I was.

Which is brilliant, because it perfectly captures the two things that make this whole situation unbearable:

• it’ll happily invent a number with complete confidence
• then it’ll immediately agree with whoever pushes back hardest

The worst part, is that Copilot is just mimicking behaviour I see every day in teams across industries. Happily throwing out a number that sounds sensible but has no grounding in reality.

That is not estimation, It’s not planning. It’s not even advice.

It’s a bullshit generator wrapped around a politeness filter.

And the industry is busy trying to bolt this onto sprint planning like it’s the missing ingredient.

Story points only mean something inside a team that has:

• a shared understanding of “done”
• reference stories to anchor comparisons
• enough history to calibrate what a “3” feels like here
• the maturity to call out uncertainty instead of masking it with a number

Without that, a point value is just vibes with a number attached.

If you want AI to help, let it help where it can actually add value:

• list likely unknowns and risks in the ticket
• suggest questions to ask before you start
• identify impacted modules and integration points
• propose ways to slice the work smaller
• generate candidate acceptance criteria
• highlight test considerations and edge cases

That’s useful.

But unprompted “5 points” is not useful. It’s estimation theatre with a silicon mask on, and a customer service reflex that will agree with everyone in the room.

Which, to be fair, is also how a lot of agile transformations are run.

So what should you do instead

You have a few options. Pick the one your organisation is actually ready for, then move towards better.

Option 1: Make story points boring again

If you insist on keeping points, at least do them properly:

• Stop converting points to time. If someone asks “how many days is a 5”, the answer is “that’s not what it means”.
• Create reference stories. A small set of agreed examples (1, 2, 3, 5, 8) that everyone can compare against.
• Estimate uncertainty, as well effort. If it has unknowns, it is bigger. If it crosses boundaries, it is bigger.
• Do it quickly. If it takes more than a few minutes, you are missing information. Capture the questions, then move on.
• Never use points to measure individuals. That way lies madness.
• Treat velocity as internal. Use it to help the team forecast, not to report “productivity” upwards.

This does not make points perfect, but it stops them becoming harmful.

Option 2: Slice work until estimation becomes mostly irrelevant

Most estimation problems are actually slicing problems. This is my personal favourite.

If your “story” contains three systems, multiple roles, and vague acceptance criteria that reads like a prophecy, no estimation technique will save you. Break it down.

Aim for work that is:

• small enough to finish inside a day or so.
• testable without a committee
• meaningful on its own
• low in hidden dependencies

When work is small, forecasting becomes easier, risk becomes visible, and you stop needing to argue about numbers.

Option 3: Forecast using real delivery data

If you want predictability, stop pretending it comes from estimates. It comes from flow.

Track:

• cycle time (how long work takes once started)
• throughput (how many items you finish per week)
• work-in-progress (how much you start but do not finish)

Then use probabilistic forecasting. Monte Carlo forecasting is a common approach because it uses your actual historical data to generate ranges like:

• “there’s an 85% chance we finish by X date”
• “most likely range is between Y and Z”

Stakeholders hate this at first because it is honest, but it is far more useful than fake certainty. If you couple thiswith option 2, this is super powerful.

Option 4: Estimate at the right level

Estimate big things coarsely. Deliver small things precisely.

Use T-shirt sizing for epics (S, M, L, XL) or simple relative buckets. Use it to make prioritisation decisions and roadmap trade-offs.

Do not pretend you can estimate small implementation details months in advance. That is how roadmaps become fiction and teams become tired.

The uncomfortable truth

The problem is not story points. The problem is what people want story points to do.

They want them to remove uncertainty. They want them to create certainty where none exists. They want them to justify promises made too early.

Story points cannot do that. No process can do that.

What you can do is build a system that learns quickly, ships in small batches, measures flow, and tells the truth about risk. That is how you get predictability in software. Not by arguing whether a ticket is a 5 or an 8.

If you are currently trapped in story point hell, start with one change: stop converting points to time. Watch how many other problems suddenly become obvious.

Then fix those.

Gary Worthington is a software engineer, delivery consultant, and fractional CTO 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 improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance