How to Perform Estimations in Agile Projects

How to do estimation in Agile Projects?

Table of Contents

1. Introduction
2. Techniques in estimation
3. The Estimation Scale
4. Planning Poker
5. Cartoon Representation of Planning Poker: Scrum Team
6. Relative Sizing
7. Summary

Introduction

This probably helps you to apply various techniques to derive the right estimation or your projects. Before you get into this if you did not read my previous article "How to start planning and estimating projects in Agile?" then please read that first and then return here to get the perfect insight on estimation.

Spend a little time on estimating rather than putting too much effort into it.

Suppose you are planning to service your Air conditioner in your bedroom. If you service it yourself you could wash the exterior, interior and the slider. You might think it needs an one hour to do. In another way, if you call the AC mechanic and ask them to service it then he would need three hours but they will do a complete in and out service of the Air Conditioner in a perfect manner.

What have we learned from this example? We can often spend a little time thinking about an estimate and come up with a number that is nearly as good as if we had a lot of time thinking about it.

When doing estimates, always spend a little time to estimate it rather than doing so much calculation to do the estimate. No matter how much effort you have put into estimating, it is never accurate. No amount of additional effort will make an estimate perfect. The little effort you put into an estimate of the accuracy of an estimate, it will vary drastically. You should not expect 100% accuracy.

Many projects try to get 100% accuracy in their estimates by putting more effort into getting more insight in budgets and schedules. But this additional work does not make any estimate perfect.

Techniques in estimation

Estimates are not created by any individual in the team, estimates are derived collaboratively by the team that includes who will do the work. They will discuss and complete the size of the story by throwing the reasons each one is having about it. We should always measure the size of work by using the story points. A story point is an arbitrary measure used by scrum teams to measure the effort required to implement a story. For further detailed information about story points, please refer to my earlier article "How to start planning and estimating projects in Agile?".

The estimation Scale

An estimating scale is nothing but what values the stories will be categorized with. The following are the estimation scales we shall use for the estimating:

• 2, 3, 5 and 8
• 1, 2, 4 and 8

The first one is the Fibonacci series and it is an useful estimation sequence because the gaps in the sequence become approximately larger as the numbers increase.

The second one is has each subsequent number as twice the number that precedes it.

Each of these numbers should be thought of as a bucket into which items of the appropriate sizes are poured into. Rather than thinking of work as water being poured into the buckets, think of the work as sand.

As Mike Cohn suggests, we should choose the first one since the order of magnitude of that is one. The small user stories should be estimated with the first approach.

Planning Poker

Planning Poker is a best Agile game to estimate stories in an enjoyable manner.

Planning Poker = Expert opinion + analogy +disaggregation + FUN

Expert Opinion: An expert is asked how long something will take or how big it is. But this approach is less useful on Agile projects.