When doing estimates with relative sizing techniques, we recommend using numbers in the Fibonacci sequence rather than t-shirt sizes (S, M, L), 1-10, percentages, or other similar values. While you *can* use any sequence you want, Fibonacci has specific features that help you do better relative estimates and make your estimates more useful.

Numbers in general are useful because you can add them up to create a velocity value, which helps the team plan their sprint and can tell the Product Owner how many sprints it will take the team to complete an estimated backlog of work.

The differences between the increasing amounts are in a simple, calculatable sequence, which makes the concept easier to understand. (1+1=2, 1+2=3, 2+3=5, 3+5=8, 5+8=13, etc.)

Fibonacci values are whole integers. Decimal or percentage values provide too much granularity — more than you need for a quick estimate — and potentially get the team stuck on minutia. Fibonacci forces the team to choose between more or less / bigger or smaller, which helps the team group and differentiate the size of tasks more quickly.

Fibonacci numbers are exponential: they grow at an increasing rate. Again, we want quick estimates, so the larger steps between choices encourage us to focus more on big differences than small ones that don’t matter much.

Human beings are better at estimating small chunks than big ones. The short spans (1, 2, and 3) at the beginning of the Fibonacci sequence emphasize this for us. They show a high degree of certainty, while the higher spans between larger values (5, 8, 13, etc.) show the increasing degree of uncertainty for larger values. Estimates become more efficient and effective when uncertainty is built in.

Fibonacci is non-linear and the most frequently used numbers are prime. This reduces overanalysis and guides us away from the “Just put more people on it and divide the work” trap. Since large tasks are not squares, most numbers are not divisible by anything (although they can be broken up into existing values in the sequence). Using non-linear prime numbers forces us to consider how we divide a big story up further than “just cut it in half.”

In a new team’s early days, before they build up a backlog of relative size comparisons, you can still usefully apply Fibonacci values as “days of work.”*

The sequence shows up extensively in nature, and it’s cool and nerdy. And sometimes that’s enough.

*Note: We do *not *recommend equating these values to actual development days after the first few sprints, as doing so tends to be less accurate and implies a precise commitment, not an estimate. Also a single engineer shouldn't be assigned more than 8 points of work in a sprint if you use that temporary baseline, as you need to also account for other activities. Once your team has some baseline stories to compare to, start comparing new user stories to those for relative sizes.

## Comments