Estimating, what’s it all about?

According to wikipedia, estimating is the process of finding an approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.

IRL estimating is hard. For most dev types it could possibly be the hardest thing they do and definitely the most anxiety inducing! It is important to take into a account a lot of factors when estimating to help others make decisions that affect the whole team — people just can’t take the pressure. But don’t fear because estimates are just that, estimates! (see definition above). It is not a pinky-promise.

Another thing to remember is that you don’t have to estimate alone — don’t forget, we are all about the team (team work makes the dream work). The great thing about estimating as a team is that each person brings a unique viewpoint.

So, why do we estimate? Two really great reasons to estimate are sprint planning and monitoring. When using estimates in your sprint planning it helps to work out the velocity of your team, i.e. how much work they can tackle in each sprint. In regard to sprint monitoring you can work out your burn down, i.e. how much work is remaining or burn up, i.e. how much work has been completed and the total amount of work.

When estimating there are a number of things to consider — complexity, any risks or unknowns, repetitive tasks, all stages to “done” (design, development, testing, deployment), previous experience, different opinions etc, etc. Estimating isn’t just about how much time it will take to complete.

There are a number of estimation techniques that you could use including t-shirt sizing, dot voting, the bucket system and affinity grouping. Here we tend to focus on Planning Poker to estimate. Planning poker uses the Fibonacci sequence which translates into story points. Story points rate the relative effort of work, which is helpful as it forces the team to think outside the box about a task and not just the time it takes to complete.

Planning poker uses a deck of cards with the values 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which represent the story points. To play planning poker, the team discusses the feature and then secretly selects one card to represent their estimate. All cards are then revealed at the same time. If there is a SNAP and the team selects the same estimate… then, you guessed it, that is the estimate. If not, then the team discusses their estimates and re-selects one card and reveals them at the same time….and so on and so on, until there is team consensus. If there is no consensus, perhaps that task needs some more information.

Some hot tips from our team to yours:

• Be realistic.
• Estimating is for your team’s benefit, it is not bureaucratic.
• We don’t know what we don’t know.
• Estimates can change — they aren’t set in stone! (Remember they are just estimates….see definition above)
• We suggest estimating bugs — otherwise where do they go (apart from under the sofa to breed and survive off biscuit crumbs)
• Break down large stories that are >= 8 points.
• Learn from your previous experience doing similar tasks.
• Review your estimates when a task is moved to “Done”.