Story Pointing: The Most Argued-About Thing That Rarely Delivers the Argument

Few things in Scrum spark as much debate as story pointing. I’ve genuinely witnessed Scrum Masters come perilously close to a fist fight arguing over whether story points are mentioned in the Agile Manifesto. (For the record: they’re not. Also for the record: throwing hands would not have made them more agile.)

And that, in a nutshell, is the problem.

Story pointing was never meant to be the thing. Yet I’ve watched teams, coaches, and organisations tie themselves in knots over scales, conversions, and purity tests—as if agile delivery lives or dies by the number written on a sticky note.

It’s like standing around arguing about the colour of a machine while nobody checks whether it actually works. Entertaining, perhaps. Helpful? Not so much.

Why Story Pointing Is So Divisive

At its heart, story pointing is about one simple thing: understanding a team’s capacity.

That’s it.

• Not precision.
• Not prediction.
• Not performance measurement.

Yet somewhere along the way, story points picked up a lot of baggage. I’ve worked with organisations that genuinely believed they were “agile” purely because they were using story points—despite still pushing unrealistic deadlines, overloading teams, and measuring success by utilisation.

Apparently, once you’re pointing stories, everything else magically takes care of itself.

Spoiler: it doesn’t.

When story points become the focus, the conversation shifts from learning to defending a number. And once you’re defending numbers, you’re no longer solving the real problem—which is how to create a high-performing team that can sustainably deliver value.

“Why Don’t We Estimate in Days?”

Ah yes. The classic debate.

The theory goes: estimating in days is bad, story points are good, and anyone who mentions time clearly hasn’t read the Scrum Guide enough times.

In practice? I’ve worked with plenty of new teams who are already struggling—new domain, new tech, new people—and then we drop relative sizing, Fibonacci sequences, and abstract scales on top of that and wonder why planning feels painful.

Here’s my heretical view: if a team is struggling with the concept, let them estimate in days.

It gets them moving. It helps them understand flow and capacity. And most importantly, it lets them focus on delivery rather than feeling like they’re failing an agile theory exam.

The goal isn’t estimation enlightenment. It’s helping a team plan, learn, and improve.

Complexity, Time, and Other Agile Myths

There’s a persistent belief that if you mention time, you’ve somehow abandoned complexity-based estimation.

You haven’t.

You can still talk about complexity, risk, and unknowns while acknowledging time exists. You can compare work to previous work. You can say “this feels twice as big as that” without ever touching story points.

And if you really want relative sizing? You don’t actually need story points to do it. I’ve seen teams use reference stories, t-shirt sizes, buckets, and yes—occasionally days—and still have far better conversations than teams obsessing over whether something is a 5 or an 8.

Story points are a tool. Not a religion.

“But Won’t This Lead to Comparing Teams?”

Only if you’re already measuring the wrong things.

Teams don’t get compared because they estimate in days or points. They get compared because organisations choose to treat delivery metrics as performance metrics.

I’ve worked with companies obsessing over velocity while having no real idea whether the work being delivered was valuable, usable, or even needed. Faster doesn’t mean better. It just means faster.

If we really care about agile outcomes, we should be asking:

Did this deliver value?

Did it solve a real problem?

Did it improve outcomes for users or the business?

Capacity helps with planning. Value tells you whether the work mattered.

Where the Real Value Actually Lives

Here’s the bit that somehow gets lost in all the arguing:

The value of estimation is in the conversation, not the number.

It’s in:

Surfacing assumptions

Exposing unknowns

Aligning understanding

Spotting risks before they hurt

Whether the output of that conversation is story points, days, t-shirt sizes, or bananas is largely irrelevant.

And just to be clear: I’m not anti–story points. I’m very much in favour of sizing work based on previous delivery, complexity, and uncertainty. Used well, story points can be incredibly useful.

But when they become the thing teams argue about—rather than a way to understand capacity—they’ve stopped serving their purpose.

Over to You

I’ve seen teams nearly come to blows over story points. I’ve worked with organisations convinced they were agile because they used them. I’ve also seen teams quietly deliver brilliant outcomes while estimating in ways that would make an agile purist wince.

So I’m curious—what’s your experience?

Have story points helped your team, or become a distraction?
Do you estimate in points, days, or something else entirely?
And have you ever watched a meeting derail over a number that didn’t really matter?

Strong opinions welcome. Just maybe leave the fist fights out this time.