Thoughts·Aug 25, 2026

Story points were always days

Every team I've worked on keeps a private conversion table. Three points is a day and a bit, five is most of a week. Nobody writes it down and everybody has one.

An abstraction that needs a conversion table isn't an abstraction. It's a unit with the label scraped off.

The unit was time from the start

Story points didn't start as a measure of complexity. They started as days.

Ron Jeffries, who takes responsibility for coining the term, has written about the origin. Stories in XP were estimated in ideal days — the time the work would take if nobody interrupted you — and then multiplied by a load factor to get real days. The factor was usually about three.

That's a time estimate with a fudge multiplier. Reasonable thing to do, and obviously an estimate in days.

Jeffries went further in 2019. He said that if he did invent story points he's a little sorry, that they're widely misused, and that most teams would lose nothing by dropping story estimates altogether. When the person credited with the practice tells you that, it's a clear sign to abandon ship.

The conversion is structural, not sloppiness

The standard response is that teams doing this have misunderstood the technique. Points measure relative complexity, velocity emerges empirically, stop thinking in days.

But the business isn't asking a complexity question. It's asking when. Points don't answer that, so the conversion has to happen somewhere, and it does. Every velocity calculation is that conversion, performed in public with a spreadsheet. Multiply points by a historical rate and you have a date. The private table each engineer carries is the same arithmetic, faster.

Telling teams they're estimating wrong asks them to stop doing the one thing the number exists to enable.

One number, several people

Sit through enough planning and the same question comes up. Does this include testing? Sometimes review, sometimes the deployment. The team settles it by convention, the convention drifts, and somebody asks again three months later.

That argument only has stakes because everyone knows the number gets divided by a velocity to produce a date. If points really measured relative complexity, including testing or not would rescale every ticket by about the same factor and change nothing. Velocity would absorb it inside two sprints. The question keeps coming back because the team is thinking in effort, and testing is effort.

Underneath it sits a harder problem. A ticket isn't worked by one person. A change moves through implementation, review, testing and usually a deployment, some of it sequential, some of it parallel, done by people with different skills and different amounts of context. One number has to stand for all of it.

Time at least composes. You can add person-days. You can tell the difference between five person-days and five calendar days. You can see that one person is the bottleneck and that adding another won't help. A complexity score does none of that. It doesn't break down into who does what, and it doesn't add back up either: three points of implementation and three points of test work aren't six points of anything.

So teams pick between two bad options. Either the number covers one person's implementation and the estimate quietly excludes half the work, or it covers everything and becomes a blended average across people whose contributions you can't see any more.

Most teams pick the first, then wonder why every sprint ends with tickets stuck in review.

What the ritual actually buys

Twenty years is a long time for a practice everyone privately admits is a time conversion. Something keeps it alive.

Points buy deniability, and they buy it for both sides. The engineer hasn't committed to a date, so a miss isn't a broken promise. The manager passes a forecast upward without owning one either. If you've worked somewhere that punishes a missed date, you know why that's valuable.

It just isn't estimation. If what we're buying is political cover rather than prediction, we should at least know that's the purchase.

Dimensionless numbers can't be argued with

A day estimate is falsifiable. Anyone in the room can say a similar change took two days last quarter, and the estimate has to answer for itself. Eight points can't be challenged from outside the team, because eight points doesn't mean anything outside the team.

That gets sold as protection from pressure, and sometimes it's exactly that. It also means bad estimates never get corrected by knowledge held elsewhere in the building.

Then velocity gets Goodharted, on schedule. When the number needs to go up, points inflate to meet it, and nothing catches the drift because there's no external anchor to catch it against.

A day is a day. A point is whatever the team decided it was that moment, and last quarter's figures aren't evidence of anything.

Where sizing does earn its keep

The value is in the disagreement, not the number. When two people size the same ticket at 2 and 13 they're describing different pieces of work, and finding that out before anyone starts pays for the meeting.

You get the same thing from any sizing conversation, including asking how long. Coarse T-shirt triage across a backlog nobody has committed to is cheap and fine. The trouble starts when the number leaves the room and turns up on a slide.

Count what already exists

The tracker already knows how many tickets finished last week and how long each one sat in progress. Throughput and cycle time need no consensus and no ritual, and they have units that survive contact with people outside the team.

Run a Monte Carlo simulation against historical throughput and you get a distribution over dates instead of a single number: an 85% date and a 50% date, both generated from what the team actually did. Daniel Vacanti's work is the standard reference. It does need enforced WIP limits and a process stable enough that last quarter resembles this one, which is a real constraint and I'd rather say so than sell it as free.