Agile Estimation

Schedules used to be built out of time. Three days for a screen, five for the server side, add up every line and the launch date falls out the bottom. The arithmetic was tidy. The dates were usually wrong.

Two things kept breaking them. The first is that the same task takes different people different amounts of time. Work that takes a day for someone who has been in that code for three years takes four days for someone who joined last month. The meeting notes record a single number, but there are really three numbers depending on who picks the task up — and at planning time nobody has been assigned yet.

The second is that an estimate spoken in days turns into a promise on the way across the table. Someone asks how many days a feature will take. The engineer imagines the worst case and says eight. "Why so long?" comes back, eight gets negotiated down to six, and the six is met by skipping review and testing. Next time the engineer says twelve, because twelve survives being cut. At that point the number has stopped measuring the work and started tracking who has leverage in the room.

Agile estimation breaks that loop by changing the question. It doesn't ask how long something will take. It asks how big it is next to work the team has already done. People are bad at guessing whether a task is a three-day task and quite good at picking which of two tasks is larger. Asked to name the weight of two bags in grams, almost everyone is wrong; asked which bag is heavier, almost nobody is. Comparison is the judgment people are reliable at, so the method only ever asks for that one.

Time doesn't disappear, it just moves later in the process. Run a few cycles with sizes attached and the team accumulates a record of how many points it actually finishes per cycle — that average is called velocity — and the record converts sizes into dates. The schedule ends up answered by history rather than by whoever felt most confident or most pressured. This does assume a way of working like agile, where short cycles repeat and each one produces something. Without repeating cycles there is no record to build, and a size stays nothing more than a size.

The terms under agile estimation fall into four groups: what the sizes are measured against (principles), what the sizes are written in (units), how several people's private numbers become one number (techniques), and the argument for skipping the whole thing (alternatives).

Principles cover why comparison works at all. There are two.

1. Relative estimation — pick one piece of work as the reference and size everything else against it. The team agrees that building the login screen is a 3; a new item that feels about twice that size gets a 5, one that feels half gets a 2. Because the reference is a private agreement inside one team, the resulting numbers don't compare across teams.
2. Cone of uncertainty — a model of how the error on an estimate depends on when you make it. Before anything is built, actual effort can land up to four times away from the estimate. Halfway through the build, that spread narrows sharply. So a number written into a quarterly plan and a number written into this cycle's plan don't carry the same weight, even when both are the same size. This is also why a team that re-sizes an item just before starting it often lands on a different number than it wrote three months earlier, and why that change is a sign the model is working rather than a sign someone estimated badly.

Units are the scale the size is written on, and the story point is the one most teams use. The usual values are 1, 2, 3, 5, 8 — spaced apart on purpose, so nobody spends ten minutes arguing whether something is a 6 or a 7. Larger work carries more error anyway, so the marks should get coarser as they get bigger. Since the scale isn't made of hours, converting 8 points into 8 days isn't a valid move. When a value climbs to 13 or 21, most teams stop refining the number and split the item instead: an item that large is a signal that something inside it is still unknown, and splitting it in two and looking at each half is faster than trying to get the single number right. Some teams add a special value for "too unclear to size," which routes the item to a short investigation instead of a guess.

Techniques are procedures for turning several private numbers into one. There are two, working at different levels of coarseness.

1. Planning poker — everyone picks a card for one item and reveals at the same moment. Revealing simultaneously keeps the first number said out loud from dragging everyone toward it. When the cards come back as a 3 and a 13, both sides explain, and what usually falls out is a missing fact like "this one touches the payment integration." Reaching a number matters less than surfacing that fact. The cards are re-played after the discussion, and the second round usually converges without anyone being talked into a number.
2. T-shirt sizing — sort items into rough grades like S, M, L and XL. Grades don't add up the way numbers do, but they let a team sweep dozens of untouched chunks in an hour. Use them at the wide end of the cone, in quarterly planning. Ten items at L or above tells you the quarter won't hold all of it, and that alone is enough to make the next decision.

Alternatives argue for cutting the procedure out. No estimates says to spend the estimating time on slicing work smaller instead, and to plan from how many items recently finished rather than from a sum of sizes. If every item is trimmed to two or three days, counting items predicts as well as adding points does. It reads less as a claim that estimating is useless and more as a marker for the point where estimating costs more than the accuracy it buys. It also demands more slicing discipline than the other three groups, so a team that lets item sizes drift ends up with worse forecasts, not better ones.

The four groups aren't a menu to pick from — they stack. The principles justify the scale, the scale gives the techniques something to collect, and the collected numbers move into planning. What receives them is capacity planning, the work of counting how much this team can actually absorb next cycle. If estimation measures the size of the work, capacity planning measures the size of the container, and neither one alone produces a plan. Pick 40 points of items without knowing that next cycle holds three days of vacation and two days of hiring interviews and the 40 is just a number on a page.

"This is bigger than a 5. The moment payments are involved there are three more screens to verify, so I'm moving it to 8."

An item that looked the same size as its neighbors has scope nobody counted, so it gets bumped one step up the scale.

"Please don't convert points to dates in the report. An 8 doesn't mean eight days."

A warning that turning a relative size into absolute time is what makes the number read as a promise.

"There's too much we don't know to size this, so I'll spend a day on it and put a number on it afterward."

The error band is too wide to be useful right now, so investigation comes before the estimate.

At Pagedeck these lines show up in sprint planning, the meeting where the team picks what goes into the coming cycle. Mia reads the candidate items one by one, engineering reveals cards, and only the items where the numbers split take any real time. When Theo plays a 3 and someone across the table plays a 13, a sentence like "this one has to touch notification settings" follows, and after that sentence the item usually gets split in two. In an hour-long session maybe three or four items out of twenty actually change value; the rest come back unanimous and pass in thirty seconds.

When Grace asks about the quarter, the same team reaches for a coarser tool. Putting points on twenty untouched chunks would take half a day, while t-shirt grades sweep them in an hour and leave a shortlist of everything at L or above to look at next month. The grades aren't used because they're precise. They're used because the only thing needed right now is the fact that not all of it fits in the quarter, and that fact survives a coarse tool. Anything that reaches the top of that shortlist gets sized properly later, once the team is close enough to the work for a point value to mean something.

The most common mistake is believing there's a hidden conversion table behind the points — 1 is half a day, 3 is two days, 8 is a week. It's an easy belief to arrive at, since the conversation has to end in dates eventually, and talking only about size can feel like dodging the question. What actually happens is that building the table cancels everything the method was for. Relative sizes exist to take individual speed out of the number; attaching hours puts it straight back. Leave it in place and meetings return to their old shape. The developer who played a 5 gets asked why a "four-day" item isn't done in three, and from the next cycle everyone quietly plays 8 to be safe. The padding is rational for the person doing it and corrosive for the plan, since every future number now carries a margin nobody can see or subtract. Six months later the same work is sized 8 instead of 5 and nothing about the work has changed.

The second mistake is reading an estimate as a prediction that has to come true. Writing a number down and then wanting it to be right is a natural instinct. But these numbers aren't built to be right about one item; they're built so that errors across many items cancel out. A 3 finishing in a day and a 5 taking three days happens constantly, and across twenty items that scatter collects near the average. Adding meeting time to sharpen one item inflates the cost of estimating and barely moves the accuracy of the total. When a session spends more than about fifteen minutes on a single item, the item wants splitting, not more debate. The second number is rarely better than the first; the smaller item is.