Your team estimated the sprint at 34 points. It shipped in nine days instead of five. Nobody's surprised anymore, and that's the problem. When your estimates are wrong often enough that everyone shrugs, the estimate has stopped doing its job.

If you manage engineers or run standups, you already know the ritual. Poker cards, Fibonacci numbers, a debate about whether this ticket is a 3 or a 5. Everyone leaves the room with a number that feels rigorous and predicts almost nothing about when the work will actually be done.

This post makes a specific argument: story points lie because they measure the wrong thing, and a boring 3-bucket sizing system predicts calendar time better. Here's how to run it.

Key takeaways

  • Story points measure relative complexity, not calendar time, so they can't answer the only question stakeholders ask: when.
  • Points inflate over time, break across teams, and turn into a velocity metric that's easy to game.
  • A 3-bucket system (Small, Medium, Large) forces a clarity conversation instead of a false-precision one.
  • Track how long each bucket actually took, then let history do your forecasting.
  • The goal isn't a perfect number. It's a small, consistent range you can plan around.

Why story points lie

Story points started as a clever workaround. Humans are bad at estimating hours and slightly better at estimating relative size, so points asked "is this bigger or smaller than that?" instead of "how many hours?" Reasonable idea. Then it drifted.

Points measure complexity, stakeholders care about time

A 5-point ticket and a 3-point ticket tell you their relative complexity. They tell you nothing about whether either ships this week. Complexity and calendar time are correlated, but loosely, and the gap is where your roadmap dates go to die. Your VP doesn't ask how many points are left. She asks what date it's done.

Points inflate

Watch any team over two years. Last year's 3 is this year's 5. Nobody decided to inflate; it happened one slightly-generous estimate at a time. Which means velocity trends up even when the team ships the same amount, and "we did 40 points last sprint" becomes meaningless as a baseline.

Points don't survive contact with other teams

Your team's 8 is another team's 3. There's no shared unit, so points can't roll up across an org. The moment leadership tries to compare velocity between two squads, someone learns this the hard way.

Points get gamed the instant they become a target

Once velocity shows up in a performance review or a stakeholder deck, estimates quietly grow. Not out of malice. It's just what happens when a measurement becomes a target. Goodhart's law runs your sprint planning now.

The estimate that matters is the one that helps you decide what to commit to this month. Everything else is theater.

The 3-bucket system: S, M, L

Here's the alternative. Three buckets. That's the whole system.

  • Small — you understand it fully. No unknowns. One person, roughly a day or less. "Add a field to this form."
  • Medium — you understand most of it, with one or two open questions you can answer quickly. A few days. "Wire up the new endpoint and the UI that calls it."
  • Large — real unknowns, dependencies on other people, or a design you haven't nailed down. More than a few days, and honestly you're not sure. "Migrate auth to the new provider."

Notice what the buckets are really sorting: how much you know. A Large isn't large because it's hard. It's large because it's uncertain. That's the signal you actually want, because uncertainty is what blows up calendar dates.

Why three buckets beats twelve numbers

Fibonacci gives you 1, 2, 3, 5, 8, 13, 21. Seven options for a thing you can't measure to that precision anyway. False precision invites debate. Three buckets end the debate fast: is this understood, mostly understood, or fuzzy? You'll reach consensus in seconds, and the conversation you skip ("is it a 3 or a 5?") was never worth having.

The Large bucket is a to-do list, not an estimate

When something lands in Large, don't estimate it harder. Break it down. A Large should be split into Smalls and Mediums before it enters a sprint, or explicitly flagged as a spike to reduce the unknowns first. The bucket isn't a size; it's a warning light.

Make the buckets correlate with calendar time

Buckets alone are just t-shirt sizes, and t-shirt sizes have the same problem as points if you never check them against reality. The step everyone skips: record how long each bucket actually takes, then read it back.

Track actuals, not estimates

For a month, log the real elapsed time for every Small, Medium, and Large you close. Not the guess. The actual. After a few dozen tickets you'll have a distribution: maybe Smalls cluster around a day, Mediums land between two and four days, Larges are all over the place (which is exactly why they shouldn't enter a sprint whole).

In Zoobbe, you can put an S/M/L single-select custom field on every card and run a stopwatch or countdown timer on the work as it happens. Sessions get logged with durations, so the actual time is captured while people work instead of reconstructed from memory on Friday. That's the raw data your forecast runs on.

Forecast with ranges, not points

Once you know a Medium is "usually two to four days," planning gets honest. A sprint with four Mediums and six Smalls has a defensible range you can hand to a stakeholder, with the uncertainty stated out loud instead of hidden inside a tidy 21-point total. Ranges feel less impressive than a single number. They're also far more likely to be right.

Let automation move the work, not your standup

You can wire automation rules so that when a card is sized Large it gets a label and a comment flagging it for breakdown, or so cards moving into a sprint list get assigned and dated automatically. The point is to spend your planning meeting on the one real question (do we understand this?) instead of on bookkeeping.

How to roll this out without a mutiny

Don't announce that story points are dead. Run the buckets in parallel for two sprints. Size everything both ways, track actuals, and let the team see for themselves which one predicted the finish date. The data makes the argument you don't want to make in a meeting.

Then drop the points. Keep the buckets. Keep tracking actuals, because the day you stop measuring is the day the buckets start drifting the same way points did.

FAQ

Isn't S/M/L just story points with fewer numbers?

The difference is what you do next. Points end at the number. Buckets are paired with tracked actuals, so the size maps to a real calendar range from your own history instead of an abstract complexity score. And because a Large explicitly means "break this down," the system forces the clarity work that points let you defer.

How many tickets before the actuals are trustworthy?

Rough guidance: a few dozen closed tickets per bucket before you lean on the ranges. Early on, treat the numbers as directional. The distribution tightens as you accumulate history, and it's specific to your team, which is the whole point.

What about long-term roadmap estimates, months out?

Sizing is for work that's understood well enough to start soon. For anything months out, you're guessing at scope, not effort, so a bucket is premature. Use Large as a signal that a thing needs discovery before it can be sized at all.

Does this work for teams that aren't engineering?

Yes. The buckets sort by uncertainty, which is universal. Any team doing knowledge work with variable-size tasks can size S/M/L and track actuals the same way. Engineering just happens to be where story-point orthodoxy runs deepest.

Do we still need velocity?

You need a sense of throughput, and "how many Smalls and Mediums do we typically close per sprint" gives you that without the inflation problem. What you don't need is a single points number in a stakeholder deck, because that's the one that quietly grows until it means nothing.

Estimate less, measure more

The uncomfortable truth is that estimation is guessing, and no numbering scheme changes that. What changes your accuracy is measuring what actually happened and feeding it back in. Three buckets, tracked honestly, will out-predict any point system, because they're built on your team's real history instead of a room full of poker cards. Try it in Zoobbe and let the actuals settle the argument.

Photo by Andy Brown on Unsplash