Relative Estimation

The unit used for asking about schedules was, for a long time, time itself. How many days will this take, answered in days. That approach cannot explain why the same piece of work gets different answers from different people.

The problem surfaced in a Pagedeck cycle planning session. Against five items, Theo wrote 2, 1, 3, 5 and 2 days; another engineer wrote 4, 2, 5, 8 and 3 for the same five. Both sets were honest numbers. Theo had written that code the previous year and the other person was opening it for the first time. The totals came out as 13 days and 22 days, which means the plan can't be made until it's settled who takes the work.

Human judgment is lopsided in a useful way. People are poor at absolute time and reasonably good at comparing the size of two pieces of work. The judgment that this item is roughly twice that one comes out similar from two people with very different experience. Relative estimation is the approach that uses only that ability. Under agile estimation, gauging the size of work on a relative basis instead of in absolute time, it belongs to the principle group, the one covering why the approach holds up at all.

Five steps make up the procedure.

1. Nail down one reference item. Everybody on the team has to know what it involves, and it shouldn't be large. Something like deciding that building the login screen counts as a 3. If that single item wobbles, everything else wobbles with it.
2. Compare each new item against the reference. Roughly twice as large gets a 5, about half gets a 2. The question being asked is not how many days but bigger or smaller than the reference.
3. Keep the scale coarse. Use spread-out values like 1, 2, 3, 5, 8; the gaps exist to remove the argument over whether something is a 6 or a 7. Larger work carries larger error anyway, so a coarse scale is the honest one.
4. Split anything past 13. An item that large means something unknown is still mixed into it. Rather than working harder at the number, cut it in two and look at each half again.
5. Don't convert to time. Build a table saying 3 points is 3 days and the approach has returned to time estimation.

The reason it holds up is that errors cancel out. Individual values are wrong often — something sized 5 turns out to cost 8. But add up twenty items and the overestimates mix with the underestimates until the total lands close to reality. The key to the whole approach is that the target is the accuracy of the total rather than of any single item.

The other thing worth watching is that values survive a change of assignee. Size is a property of the work and duration is a property of the person. Recorded as size, a 5 stays a 5 whether Theo takes it or somebody else does. Recorded as time, everything has to be re-estimated whenever the assignment changes. The scale those sizes get written in is called story points, and gathering several people's numbers into one usually happens through planning poker, where everybody picks a card and reveals at the same time.

It shows up in three places. Picking the items for a cycle, sweeping the backlog to attach rough sizes, and quarterly planning while items are still coarse. That last place sometimes uses t-shirt sizing instead, sorting into grades like S, M and L rather than numbers.

Turning a total into a plan is where this approach is headed. With velocity, the average points actually finished over recent cycles, there's a basis for how many points to take on this time. It pairs with capacity planning, which counts how much the team can really absorb next cycle. Pick 40 points' worth without knowing that three vacation days fall in that cycle and the 40 stays a number on a page.

Where it doesn't fit is equally clear: any place where a date has to be promised outside the team. When a customer asks when it will be ready, "8 points" means nothing to them. The answer there comes from converting through recent velocity and giving a range, two to three weeks. The conversion applies to totals only, and the answer comes out as a range rather than a single date. The width of that range is set by the cone of uncertainty, which says the error band depends on when the estimate was made.

"Is this bigger or smaller than the login screen? I'm not asking how many days."

Moving the question from time over to size.

"If it's between 8 and 13, let's not round up to 13 — split it into two."

Reading a rising value as a signal to split rather than to round.

"Don't build a table where 3 points is 3 days. That removes the reason to estimate this way."

Pointing out that a conversion table collapses the approach.

In Pagedeck's cycle planning, Mia reads the items out and the engineers play cards. Theo and another engineer landing on 3 and 8 happens often, and the conversation that follows is the real yield of the session. Usually a fact one side didn't have comes out: that a payment integration comes attached, or that another team already reworked that screen.

Agreeing on a number comes only after that. Once the conversation ends, the two values generally converge near 5.

The most common position is that points can be converted into time, because anybody who has to communicate a plan as dates badly wants a conversion table. But once a table says one point is one day, the team starts thinking in time while writing in points. Values wobble when assignments change, and a total built from wobbling values isn't a basis for a plan. When dates are needed, velocity does that job instead of a table. A table attaches a conversion to one item while velocity comes out of past results, and only the second of those doesn't shift with who is assigned.

The other frequent belief is that numbers can be compared across teams, since the scale looks shared. But the reference item is an agreement internal to a team. If team A sizes the login screen at 3 and team B sizes the same screen at 8, team B's numbers always run more than twice as high without team B doing twice the work. Start putting two teams' totals side by side to discuss productivity and teams drift toward larger values for identical work — six months later the numbers have climbed and the output shipped is the same.