# Why estimate?

• you need it to be able to forecast costs for the product (either internal production or for an external customer).
• You need it to be able to plan the releases and the roadmap.
• You need it for the current iteration, not to overload the team and as a key to make commitments.
• To prioritize the features and tasks.

How to estimate, which methodology to use is very complex: it depends a lot on the experience and attitude of the team members.

There are two sides involved in the estimation process.

# The set of values to be used

## Initially, T-Shirt size estimates

For the initial estimates you can just put the tasks into different pools, like T-shirts size: there is one for Small tasks, one for Medium and one for Large ones. If you wish more pools you can add extra-small (XS) or extra-large (XL) and so on.
When you will need finer estimations at later stages, here are other methods.

## Relative estimations

One of the most used method is using story point, i.e unit-less numbers that are relative so they can compare similar stories (that is, a two-point story should expect to take twice as long as a one-point story).
In my experience they not so easy to use by a new team; people tend to think about tasks in durations, like “I will need two hours to make this function” but a true fact – even if not so intuitive at the beginning – is that people are more comfortable making relative estimates than they are making absolute estimates.
Even more sophisticated is to use numbers derived from the Fibonacci series: 1,2,3,5,8,13,21, … (each number is the sum of the previous two). This special series has the advantage that the numbers increase exponentially and this enforces the concept that bigger is a task more complex will be to be implemented and should be split.

Mike Cohn proposed a modified Fibonacci series (his company Mountain Goat Software is selling different decks of card for estimations) that is: 0, 1, 3, 5, 8, 13, 20, 40, 100.
The lower range (until 10) is designed to help teams to estimate small things they understand well with greater precision.
However, the upper range has increasing numbers, reflecting greater uncertainty.
If the estimates reach this range, it means that the story is too big for an iteration, it represents substantial risk and needs to be split.
The values zero or 0.5 give the teams a way to ignore small stories that can be implemented in just a few minutes but are still worth to be tracked.

## Absolute estimations

The biggest hurdle when you have relative values, is that if you want to know your release date, you still have to translate the story points to actual man days: pick any user story estimated 1 point and estimate how much time it would take to implement and then do the math for the other stories.
For unexperienced teams, is often better to start using man-hours: everyone knows what man-hours are and can judge if a task will take half a day or more days. The disadvantage is that they are absolute values and have a unit (man-hours or days).
It’s usually the best choice to start with absolute estimations and to leave the relative values to a later retrospective (and some teams are so efficient in estimating absolute values that they will never need relative ones).

For example, once you know the mechanism of estimating tasks, you could start by finding out which one is the smallest story, one that can be done by one person in about a day or half day, and you estimate this as a 1. Then proceed with all other stories in a relative way.

Note: there is also the ideal team day that is the work that one team member could complete in one ideal day (no interruptions, no blocking issues, …) that is used by Scrum, but this is really just a variation on the schema above.

# Who puts a number on each task

Here too there are several methods.

Usually who volunteers for the task gets to estimate it. This assumes that the volunteer knows what is talking about but very often you get a biased result, that can be quite off at the end.

Rather than place all of the burden and responsibility for an estimate on the shoulders of an individual estimates are owned by teams.

The accepted approach for doing this is to use 3 point estimates and to converge these as a team. Techniques such as Wide Band Delphi provide techniques for combining multiple estimates with associated imprecision.
A bit more sophisticated would be to ask everyone in the team and make an average. There could be variations on this like removing from the average the highest and the lowest
Even more sophisticated would be the so-called planning poker: for each task, everyone in the team decides on an estimation value and then all together present their value. The lowest and the highest gets to explain why they think so and then the process is repeated until the members converge on a common value. The big advantage from this process is that the value comes as if it was from the whole team.

## Beware of the discussion: too much precision can harm

Sometimes when the team discusses about an estimation, it becomes personal.
One developer might say a story takes two days, another five. Both could be correct—a more skilled person in that area will need less time— but it’s not necessarily bad: more interesting discussions can result.

What you need to consider is that too many or too long or too heated discussions are not supportive of the team spirit. We do not want to shove in the faces of new team members that they are slower contributors, each time. Worse, if this information finds its way to personnel reviews, then you have major problems.

You want to keep discussions pretty fast. Suggestion is to allow two to five minutes of discussion per item, so a team should be able to estimate ten to twenty stories in an hour or so, which is about the maximum amount of time a team should spend estimating.

Spending too much time does not generally increase the accuracy of the estimates (and it bores the team!).

It is a good idea also to put a limit on the times you repeat the planning poker: two is reasonable.
Spending too much time estimating is truly a form of waste (remember the lean principles).
At the end, teams must be careful to time-box their estimating and not attempt to turn this heuristic into a pseudoscience.