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.

Analogy: When estimating by analogy, the estimator compares the story being estimated with one or more stories. We normally are better at estimating relative size than estimating at absolute size.

Disaggregation: It refers to splitting a story into smaller, easier to estimate pieces.

Planning Poker combines the expert opinion, analogy and disaggregation into an enjoyable approach to estimate the results in quick but reliable estimates.

The Following cartoons dialogue will clarify "How to play Planning Poker game for the estimation?".

Cartoon Representation of Planning Poker: Scrum Team



At Morning 9 AM in the Discussion Room, everyone in the team assembled for doing the stories estimation. Each estimator is given a deck of cards that read 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.


           
As a first step, Rajesh, the product owner explains the story to the team. Everyone listens carefully to what he is saying.

          
                                 
During the explanation Sundar has a doubt.

            

 

After all the questions answered by the product owner (Rajesh), now each estimator privately selects a card representing his or her estimate that are shown at the same time:


 
Now each estimator's estimate differs significantly; if the estimates differ then the high and low estimators should explain their estimates.
 
After the explanation from Karthik and Priya, the team discussing the story by themselves is saying, how big is the story?



After the team discussion, each one takes his/her own private card again with the discussion points in mind.



At this point, there is not much difference among the team members. In other words, each one has agreed to the value 8. So the estimate of this story is 8. If there is a significamt difference among the team members thenb we need to discuss it and play again until everyone is agreed to the estimate.

Advantages of Playing Planning Poker

• Brings together multiple person's opinions in a team
• A lively dialogue ensures during Planning Poker, estimators are called upon by their peers to justify their estimates
• Group discussion is the basis of Planning Poker, and those discussions lead to an averaging of sorts of the individual estimates
• Because its fun, it works well

Relative Sizing

Relative sizing is another technique in the Agile estimation by comparing all the stories with each one. It is nearly like Planning Poker. Here I shall give you the procedure relatively to size your stories:

• Have a relative frame of reference to size your stories. Pick a story that is small and assign the value as 2.
• Relatively size each story against the benchmark story by discussing only the implementation details that affect its size.
• Put each story into the bucket 1, 2, 4, 8 or 16 or 1, 2, 3, 5, 8...
• Compare it against the benchmarked story and put it in the right bucket.
• Finally you will be have a bunch of stories that are sized perfectly.

Summary

Spending more time and effort on doing estimation doesn't give you the perfect estimate. Estimates should be on a predefined scale. Scale values we shall use for estimation are 1, 2, 3, 5 and 8 or 1, 2, 4 and 8. A fun game to derive an estimate is Planning Poker that consists of expert opinion, analogy and disaggregation.