Estimation, the very word in itself seems quite heavy, and it does feel substantial when you are asked to estimate unfamiliar items to some degree. One of the key advantages of adopting Agile is the capability of the team to estimate work effectually. Earlier when the teams were on waterfall, they used bottom up approach with the smallest tasks at the bottom, in order to determine the cost of each feature. On the contrary, Agile uses two estimation techniques, such as Top-Down Estimation and Relative Sizing, since we are not concerned about the detail of the tasks. Instead, we are much more interested in swift estimates of higher-level features, or even epics.
What is Estimation?
“Estimation (or estimating) is the process of finding an estimate, or 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.” – Wiki.
I remember when my teams used to be quite first-hand at the concept of estimating the efforts, in the initial days, I could sense the uneasiness and question mark on their faces, it is the hardest part if implemented in true sense. But once they get used to it, they regain confidence.
Estimation is necessary for any planning practice;
Why to estimate?
In my last session on estimate, I asked, why do we estimate and the answers I received were-
And lastly, because that’s what we do in estimation in Agile, right? (Partially true)
But in true sense, estimates are required to plan work and time. It even helps the team to measure success in terms of numbers. Surprised! Yes they do project success, through velocity, sustained velocity figures, up rise in the numbers. Estimates can be turned into release plans too!! Even they help you make weighty decisions.
“Estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, it’s almost never an estimating problem, it’s a shared understanding problem” - MIKE COTTMEYER
How to Estimate?
Estimating work items for new teams gets quite difficult as the teams are unfamiliar with the requirements and require solution but over the time, as team members get used to the product, they develop a progressively precise sense of how they’re going to approach stories and how much effort each user story will take to complete.
As human beings, we are typically good at relatively estimating the items, e.g. we cannot predict at first instance if the Earth is heavier than Mercury, because heaviness is dependent on density which is not a visual thing to determine but we can confidently say that the circumference of Earth is bigger than that of Mercury as size is can be determined easily by visualization. Hence, we can relatively estimate the size of earth in comparison to the Mercury just by looking at it. Let’s consider the image below which shows how the product can be estimated.
Teams across the world use a variety of methods to estimate their work. You just have to find the right way of doing it, or rather the way which is most suitable for your team’s need. There is no fixed rule for estimation and luckily we live in a planet where options are not scarce and this applies to estimation as well!
Types of estimation techniques:
Accordingly, I will now be discussing some of the methods which I have personally used with my teams. Starting off with the one which is being widely used across the globe:
1) Planning Poker
Planning Poker is an Agile estimating and planning technique that is based on an agreement from the team on the points being assigned to the PBI. It makes sure that everyone participates and that every individual in the team shares his/her opinion.
To start with, each team member is given a set of cards with numbers on them. The numbers are usually in the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, and 21. The product owner reads out the story, after which, everybody in the team is asked to hold up the card showing the level of effort that they believe this story holds. Once all the votes are in, the team members with the lowest and highest estimates explain why they choose their numbers. The team then re-estimates as per the new perceptions discussed. Once the agreement has been reached that score is recorded with the story to which it relates, the team is good to proceed.
2) T-Shirt Sizes
This is a seamless technique for estimating a huge backlog of relative large items. T-shirt sizing is based on the concept of binning- a technique for accurately grouping together items of similar size. The bins are typically allocated labels matching to those commonly used with T-shirt sizes: extra small, small, medium, large, extra-large, etc.
The primary advantage to t-shirt sizes is the ease of getting started. T-shirt sizes can be a great way of becoming familiar to relative estimating. So, you can start with it if your team finds that easier.
3) The Bucket System
Much quicker than planning poker is the Bucket System. This system is a decent substitute when estimating a large number of items with a large group of participants quickly. Different buckets are created with values: 0,1,2,3,4,5,8,13,20,30,50,100, 200. The stories need to be placed within these where the estimator finds them suitable. The group estimates the items by placing them in these “buckets”. Buckets are usually different sheets of brown paper where you can place the sticky note with the item. But you can also use actual baskets to limit discussion about already processed items.
A very fast method of rough estimation is the Large/Uncertain/Small method. The team categorizes the items as per being Large/Uncertain/Small, starting with populating the extreme categories. Following which, the group can discuss the more intricate items. This is actually a generalization of the bucket system. The system is especially good to use in smaller groups with comparable items.
5) Dot Voting
When there is a relatively small set of items and you don’t want any complex techniques, you can opt for Dot Voting. This method has been coined from decision making and can be used for estimating. Each person gets a small number of stickers and can choose to vote for the individual items. More the dots, bigger is the size. This method is very simple and fast, it will work effectively to assess a small number of stories (up to 8-10).
There are many techniques that the teams use globally to estimate their work, here we have discussed the top five but there is no consensus over which method is best. Each method has its own advantages and has been customized as per the team’s functioning pattern. Like there is no common medicine that applies to all ailments, in the same way, there is no single method that applies to all for estimating. A facilitator has to understand that estimation takes time to sink in with the teams and it should not be forced upon. Go for the one which best suits your team’s need and at the same time, can provide optimum results.
Agile software environments are gaining huge growt... Read More