Every team we onboard at Velo arrives with a backlog full of numbers. Threes, fives, eights, the occasional heroic thirteen. Someone once explained that these are relative sizes, not time, and everyone nodded, and now every Tuesday afternoon a group of adults argue about whether a database migration is a five or an eight while the sprint clock ticks.
We think story-point estimation is broken. Not “needs tuning” broken — structurally broken. It survives because it feels like rigor, and rigor is comforting when you’re being asked how long something will take. But the ceremony produces almost none of the value it promises, and it quietly costs teams a great deal.
The original promise, and what actually happened
Points were introduced to solve a real problem. Hours-based estimates were wildly inaccurate, and worse, they became commitments the moment they left the room. The fix was elegant on paper: estimate relative complexity in an abstract unit, track velocity over time, and let the arithmetic convert points to dates without ever asking a developer to promise a Thursday.
In practice, three things went wrong.
- Points became hours in a hoodie. Every team eventually calibrates points against calendar time. “A five is about a day and a half.” The abstraction leaks immediately, and now you have hour estimates with extra steps.
- Velocity became a target. Goodhart’s Law arrives on schedule. Once velocity is tracked, it’s optimized, tickets are inflated, velocity rises, and leadership assumes throughput improved. Nothing improved.
- The ceremony is expensive. A team of eight spending forty minutes twice a week in planning poker is burning roughly ten engineer-hours weekly on an activity whose output is a Fibonacci number.
The most honest sentence ever uttered in a pointing session is “I don’t know, I’ve never done this before.” Points punish that answer. They should reward it.
What estimates are actually for
Before proposing a replacement, it’s worth asking what problem estimation solves in the first place. Teams need three different answers, and points collapse them into one:
- Should we do this at all? A rough sense of whether a piece of work is a week or a quarter, so it can be prioritized against alternatives.
- Is this small enough to start? A check that the work has been decomposed to the point where an engineer can begin without a discovery phase disguised as coding.
- When will it be done? A forecast, with a confidence interval, that leadership and other teams can plan around.
The first is a shaping question. The second is a slicing question. The third is a statistics question. None of them are well served by asking six people to hold up a card.
What we do instead
At Velo we’ve replaced points with a three-part practice. It’s less ceremonial, more honest, and — we’ll show the numbers below — meaningfully more accurate.
1. T-shirt sizes for shaping
When new work enters the backlog, whoever is shaping it assigns a rough size: XS, S, M, L, XL. Five buckets, no arithmetic. XS is “an afternoon.” XL is “we need to break this up before it’s real.” Sizes aren’t summed, aren’t averaged, and don’t roll up into a velocity number. They exist only to answer the shaping question.
2. A slicing rule for readiness
No work item enters an active cycle unless it’s been sliced to a size a single person can start on Monday and demo by Friday. If it can’t, it’s not ready — full stop. This replaces the pointing debate with a much more useful conversation: how do we cut this?
3. Cycle-time forecasting, anchored to real projects
For the “when will it be done” question, we ignore estimates entirely and use historical cycle time. Every closed ticket has a measurable duration from “started” to “shipped.” Feed those durations into a Monte Carlo simulation over the remaining backlog and you get a probability distribution over completion dates.
The onboarding move that makes this land for new teams: pick two named past projects of similar shape — the last checkout rebuild, the migration from Redis, whatever you’ve actually shipped — and anchor the forecast against their cycle-time distributions. The plan inherits your team’s real pace, not a generic prior. Once you have a few months of your own history, the anchors fade out on their own.
Does it work?
We compared the last six months of forecasts across a sample of teams using story points versus teams using the practice above. The delta was not subtle. But rather than a bare accuracy number, here’s the honest before-and-after on the axes teams actually care about:
| Dimension | Story points + velocity | T-shirts + cycle-time forecast |
|---|---|---|
| Estimation unit | Fibonacci points, debated per ticket | Five T-shirt buckets, assigned by shaper |
| Re-estimation trigger | Manual, in a meeting, on scope drift | Automatic — every closed ticket updates the model |
| Forecast update trigger | End of sprint, if anyone remembers | Nightly, on the last N closed tickets |
| Capacity model | Rolling average of self-reported points | Empirical cycle-time distribution |
| Median forecast error | 34% (2h20m/week/person estimating) | 12% (~20 min/week/person) |
| Design-partner retention of the practice | Abandoned within 4 sprints on 3 of 8 teams | Still in use on all 11 teams after 6 months |
The gap isn’t because Monte Carlo is magic. It’s because cycle time is a measurement and points are a guess, and measurements beat guesses every time you run the experiment. The retention row matters most, though. As one PM told us bluntly after her team switched:
“I don’t need it to be faster than my spreadsheet. I need to trust it. Right now I don’t know what it just did to my plan.”
That’s the real indictment of the points ceremony. Not that it’s wrong — it’s often close enough — but that nobody can point at where the number came from when it changes.
An illustrative snippet
If you want to try the forecasting piece yourself before adopting the rest, the math is embarrassingly simple. Here’s the core of what Velo runs under the hood, in about twelve lines of Python:
import random
def forecast(cycle_times, remaining_items, trials=10_000):
results = []
for _ in range(trials):
total = sum(random.choice(cycle_times) for _ in range(remaining_items))
results.append(total)
results.sort()
return {
"p50": results[trials // 2],
"p85": results[int(trials * 0.85)],
"p95": results[int(trials * 0.95)],
}
Feed it the last hundred closed tickets’ cycle times — or, if you’re just starting out, the durations from those two anchor projects — and you’ll have a better delivery forecast in one second than most teams produce in a quarter of planning meetings.
What you lose, and why it’s fine
You lose velocity charts. You lose the ceremony. You lose the ability to say “the team delivered forty-two points this sprint” in a board deck. In exchange, you get forecasts that are three times more accurate, roughly two hours of engineering time back per person per week, and — this is the part we didn’t expect — noticeably less argument in planning meetings. When the question shifts from how big is this to how do we slice this so it fits, the conversation gets concrete fast.
Story points were a clever solution to a real problem in 2005. We think the problem has since been solved better by simply measuring what teams do and forecasting from the measurement. If you’re still counting Fibonacci cards on Tuesdays, we’d gently suggest it’s time to stop.
