The Minimum Useful Estimate

Most teams overinvest in estimation precision. They debate whether a ticket is a 5 or an 8 for ten minutes — a distinction that has zero impact on sprint planning and even less on delivery. The time spent arguing over granularity is time not spent understanding the work.

Three sizes — small, medium, large — cover the vast majority of planning needs. A small ticket is well-understood work that one engineer can finish in a day or less. A medium is a day to three days with some complexity or unknowns. A large is more than three days and probably needs to be broken down before anyone starts.

That's it. If your team can sort tickets into those three buckets consistently, you have enough information to plan a sprint, spot overloaded weeks, and identify tickets that need more discussion. The marginal value of splitting "medium" into 3, 5, and 8 is real for some teams — but most teams don't need it, and the complexity costs more than the precision gains.

Start with S/M/L. If after a few sprints you find that your planning consistently needs finer resolution — maybe large tickets vary too much, or you're doing external commitments that need tighter forecasts — upgrade to Fibonacci or T-shirt sizes. But make that a pull decision based on evidence, not a push decision based on what a framework told you to do.

S/M/L breaks down when someone outside the team needs more than "roughly how much work is this?" Three situations push you toward finer-grained estimation:

External commitments. When a sales team needs to tell a customer "feature X will ship in Q3," the engineering team needs to estimate with enough resolution to back that date. S/M/L can't distinguish between "three weeks" and "three months." Fibonacci-scale estimates combined with historical velocity data can — not perfectly, but well enough to give a range rather than a shrug.

Budgeting and staffing. A product team deciding whether to fund Project A or Project B needs to compare their costs. "Project A is 40 story points and Project B is 90" is a rough but useful input. "Project A has some mediums and Project B has more larges" is not.

Dependency planning. When Team A's work is blocked until Team B finishes a prerequisite, both teams need enough estimation precision to coordinate timelines. "We'll be done sometime in the next sprint or two" isn't enough when a downstream team is scheduling their work around the handoff.

In all three cases, the investment in precision pays for itself because someone is making a decision based on the estimate. If nobody is making a decision — if the estimates go into a tracker and nobody looks at them — save the time.

The biggest threat to honest estimation is anchoring: the first number spoken aloud warps every number that follows. If the tech lead says "I think that's about a 3," the junior engineer who was thinking 8 second-guesses themselves and says 5. The team converges on a number that reflects the loudest voice, not the collective understanding.

Planning poker solves this mechanically. Everyone estimates simultaneously and reveals at the same time. There's no anchor because there's no first number. The spread — the gap between the highest and lowest estimate — is the signal. A unanimous 3 means the team agrees and you move on. A split between 2 and 13 means two people are imagining fundamentally different work, and that conversation needs to happen before anyone writes code.

Async estimation extends this to distributed teams. Instead of gathering in a room, engineers submit estimates independently over a window of time, with votes hidden until everyone has submitted. The anti-anchoring benefit is the same; the logistics fit teams that span time zones or can't justify synchronous meetings for every batch of tickets.

Both approaches share the same principle: estimation works best when opinions form independently before they're shared. Any method that lets the senior engineer's number influence the room before others have committed to their own estimate is leaving information on the table.