Agile Estimation Techniques

In this blog, we are going to overview the different Agile Estimation techniques.
Before we proceed, think about What is an Estimation and why we need it ?
Estimation is going through the scope of work, calculating or guessing the time required to complete the work, calculating cost of work, resources and team members required to complete the work or project and analyzing any risk, complexities and dependencies associated with the project we are taking.

Now, think about why we need to estimate before initiating the work?

Because we need better estimations so we can have better forecast and plan the project properly for below attributes:

• • Time – Start and End of the project or task.
  • Cost – Cost involved in the project, Profit %.
  • People – Human power required to complete the project.
  • Dependencies – What time the dependencies will be cleared for other dependent party.

Not only above, after all we need to have an Agreement with the parties or stakeholders involved based on above, on deliverables, dates & budget.

When you think about the estimation in software projects, we have two main estimation techniques:

1. Relative Estimation
2. Absolute Estimation

Relative estimate is based on the effort needed to finish one item compared to the other items, while Absolute estimates are based on the time required to complete the work.

Time-based estimation is a traditional way to estimate the work in hours where we have absolute commitment with that estimated time, whereas efforts-based estimates provide relative value.

Below are some different Traditional Estimation Techniques which are time based.

• • Three-point estimation
  • Top-down estimation
  • Bottom-up estimation
  • Analogous estimation
  • Parametric estimation

 

• Three-point estimating – In this technique, we have three estimates with us, Optimistic, Pessimistic and Most likely estimate.

Using the triangular or beta distribution method we calculate the final estimate numbers in these techniques. Here beta distribution is weighted average method where more weight is given to estimate most likely.

1. 1. Triangular E = (O + M + P) / 3
   2. Beta E = (O + 4M + P) / 6

• Top-down estimation – In this approach estimates are given at Epic level and further broken down to low level backlog items. Top-down estimating is a method of evaluating a project or budget as a whole and then breaking it into smaller components or tasks. With a top-down approach, the team creates an overall plan or budget for a project without defining the particulars.

 

• Bottom-up estimation – In this approach first high-level requirement is broken down in low level backlog or task and estimate for that, the overall estimate is calculated by adding the estimates of bottom tasks and moving toward the top, this is reverse approach of top-down estimates.

 

• Analogous estimating – In this approach we take a reference of previously completed work or project and by comparing the size of that work with the work which is underestimates and using expert judgement we calculate the estimates. In this diagram, you can see Project A is similar and of same size of our new project, so we are using the estimates from Project A.

• Parametric estimating – These estimates are more precise – this is statistical and accuracy-based method, in which we take a unit of work under estimation, calculate the estimate for that and then calculate the overall estimates for complete work by multiplying the unit estimate with multiplication factor relative to size of complete work.

For example, we are cleaning 1000 square feet of ground, and if we need 1 min to clean 1 square feet of ground then we need 1000 mins for completing all the work.

In below diagram, Project B is exactly 3 times of Project A which is the like new project B, we calculated the estimates for Project A and Multiplying it by 3 to know the estimate for Project B.

Another approach would be to divide Project B in three (or X) equal parts and estimate for one part, the final estimate for Project B will be the unit estimation for the unit we estimated multiplied by X (as we divided it to X equal part) + Any integration or additional time.

For example, if you have to setup 50 desktop on each floor of 10 floor building and you need 1 week per floor then your total estimate will be 10 weeks + additional time for integration and server setup.

What you read above are the traditional techniques of estimations, now see what estimation techniques we use in the Agile software development projects.

Below are the Agile estimation techniques which are more effort based rather than time based. These are relative estimation techniques rather than absolute estimation.

• • T-Shirt Size Estimation
  • Analogy
  • Dot Voting
  • Planning Poker
  • Fibonacci Sequence for Story Point Estimation
  • The Bucket System Estimation
  • Big, Uncertain, Small estimation approach
  • Maximum allowable size (MAS) estimation
  • Affinity Mapping

Will not cover all the above but let’s have a look on the most used agile estimation techniques below:

 

T-Shirt Size Estimation

This technique is useful for the teams new to Agile, in T-Shirt size estimation, we have different sizes as we have in T-Shirts – like Small, Medium, Large, Extra Large etc. which we use to tag and estimate the size of user story.

For example, let’s consider we have a backlog item which is simple, do not have risk or dependency and can be complete between 0 to 4 hours we are considering it as extra small backlog item (this is just an example, parameters and range of time can be different for different teams). Then anything has little risk or unknown scenario but still simple and can be completed within 4-8 hours we are considering of Small Size. Something a little complex and can be completed within a day or two as medium size backlog item and accordingly for other sizes like Large, extra-large etc.

Now try this estimation technique to estimate the efforts you need to enjoy the below fruits, what do you think would be the estimates to eat 10 watermelon vs 1 grape?

Benefits with T-Shirt sizing techniques are:

• • It helps with quick estimates for a substantial number of items.
  • Helps teams new to agile better, accurate & quick estimations.
  • This is a flexible approach as estimation does not change even if velocity changes.
  • It gives estimates in relative terms and not absolute numbers.
  • It is easy and effective for the new teams and the first level of estimating large backlogs.

And drawbacks are:

• • Relative estimates are not absolute, so we cannot commit anything to the client without any absolute number.
  • It may need to be converted to numerical value if a team’s velocity needs to be calculated.
  • Estimates are not uniform. One team’s T-shirt estimate may be different from that of another team.

Now, if you are using a T-shirt size estimation technique I have a question, what is your Sprint velocity?

“I don’t think you will be able to tell in absolute numbers.”

Now here, if we assign a number to each size, we will be able to relate the velocity of team to any relative number.

If I say we can deliver 2 extra small, 4 medium and 3 large size user stories in the iteration then it is not making any sense or giving us or client any achievable number.

But… by adding a numeric value to it, if I say that we can deliver 30 story points of work in the iteration then it is making more scene and giving clearer picture.

Analogy estimation:

In this technique we compare backlog items with other backlog items for sizing, we have base user story with defined estimate, and we compare other user stories with it to estimate the size of others.

In this technique, we can try to find a smallest backlog item and assign 2 SP of estimate to it, we can compare other backlog items to it, anything slightly more will be 3 SP, if anything needs double efforts than of base story will be 5 SP of work, anything half or less than base user story will be 1 SP respectively.

 

Dot Voting Technique:

We can use this technique to estimate the backlog at a high level and to prioritize the backlog, it is mostly used to prioritize the backlog. Dot Voting estimation technique has become popular in Scrum teams due to its simple approach to estimation.

Steps of Dot Voting Estimation Technique:

• • Dot Voting estimation technique suits well when there is a small team who quickly wants to estimate and prioritize a small set of items.
  • The product owner or scrum master arranges an estimation session and team members join it.
  • The product owner would write user stories on small cards before the session and will place them on the wall or the table so team can see it.
  • Every team member is given a few dots (stickers).
  • The product owner or scrum master will brief the team about the voting purpose (Prioritization or Estimate), to make it clear what this voting session expects from them.
  • When the voting begins, every team puts the dots on the stories that they think are large or need prioritization.
  • Every member will keep placing the dots until all dots are utilized.
  • Once all members have used their dots, the stories with the most dots are considered a high priority. So, the product owner arranges the stories from higher to lower order based on the number of dots they received.
  • Teams can do dot voting twice, first to decide priorities and size separately.

Below are advantages of Dot voting:

• • It gives every team member a chance to contribute to the estimation session, whether he is junior or senior and use collective wisdom.
  • It is a simple and quick way to prioritize the backlog and decision making and not have to spend more time on discussion.
  • It is a better approach for Scrum teams who are new and not experienced with other complex estimation techniques and want to start estimation with easy techniques with less effort.

There are some drawbacks of Dot Voting Estimation Technique as below:

• • If one team member expresses his/her opinion loudly, then other members might unintentionally follow his/her choice.
  • If senior members vote at the beginning, then the new or junior team members might follow their choices without much thinking.
  • Members have read the backlog items quickly and place dots, in this case some team members might not understand the backlog item and provide inaccurate estimates.
  • The voting might end up providing even votes to two or more stories and need re-estimation.
  • It is suitable only for small teams and a small list of items.
  • It provides better results if the user stories are of similar complexity. If stories have varying difficulty levels and required efforts, then estimates will be less accurate.
  • Doing both sizing the stories and prioritizing the stories in one Dot Voting estimation session is difficult, so we need two sessions for prioritizing and estimating.
  • Doesn’t suit for bigger backlog with complexities that need deeper discussions.

 

Fibonacci/Sequential Story Point Estimation

1. Sequential estimates – 1, 2, 3, 4, 5 ….
2. Fibonacci Sequence – 1, 2, 3, 5, 8 ….

The difference between these two techniques is just what pattern of numeric value series we are using for estimation. This can be used in most of the estimation techniques (Except t-shirt, dot voting…etc.).

In this story point approach, we use either of these sequential or Fibonacci series to relate the estimates and assign the story point to each backlog item based on efforts required to complete the backlog item. The main benefit is to consider this technique is that as the size gets larger, the estimation becomes less accurate.

Let’s see How Story Ponting is different than hourly estimates?

Estimating Efforts is not just about Time but …
Story point estimation includes three main components: Risk, Complexity and Repetition.

• • Risk: The risk of a particular project or item includes vague requirements or assumptions, dependencies on a third party, or anticipated changes in the mind of the task.
  • Complexity: This component is determined by how difficult the feature is to develop.
  • Repetition: This component is determined by how familiar the team member is with the feature and how monotonous certain tasks are within development.

You can relate the efforts in story pointing using the graph below, more risk and more complexity have more story points.

Now using this method, we know how many story points we can deliver in a sprint which was not a clear case for the t-shirt sizing method, which is the benefit of story point estimation, and with this we can communicate to product owner that we can complete for example 20 SP of work in the iteration.

Talking about the benefits of Agile estimation techniques, some of the benefits of Agile Estimation are that.

• It makes teams responsible and accountable for the deliverables.
• It Induces discipline across the Agile team for estimation practices.
• By predicting the approximate time to finish a project rather than absolute estimates, it gives some flexibility to the team in terms of effort.
• It helps enable better sprint management and improve the team’s productivity.
• It helps improved Decision-Making.
• It helps in backlog grooming with accurate agile estimation, and with accurate estimates and groomed backlog it helps in better sprint planning.
• Considering Risk, Repetitive and complexity factors help in better sprint planning and team coordination.
• It helps for Better Risk Management for the risk of slipping budgets and timelines as we are not using absolute estimates and story point estimates helps to stick to budget and estimates.
• With accurate estimates, there are better chances of on-time and quality delivery.

 

Now you have information on different agile estimation techniques, the questions which most of the teams often have that we are estimating in the story points, but client want it in terms of cost, hours & timeline to complete the project, so how to convert story points in the hours and cost?

 

If you know the total hours required for the project, you can easily convert it to cost for the client by multiplying it with hourly bill rate but, how to convert story points estimation to hours?

This can be done with two approaches:

Approach #1: You know that we used a range of time while estimating in story pointing, your Scrum Master can take a medium value from this. For example, on an average when he would be calculating it, he may get 1 SP = 4 hours as per the median value he calculated (or any other value based of the range he used while estimating the efforts), then he will multiple the median value by total story points and get the total hours required to complete the work and will check for your daily productive hours and your availability in sprints to commit the timeline to client.

Approach #2: In the second approach your Scrum Master will observe how many story-points the team is able to complete in a day or sprint and then calculate overall velocity to frame the timeline. We can do it using the historical velocity, for example if team is delivering 40 SP per sprint (for 1 week sprint) now if you have 2 team members in the team then we can say in 80 hours we can deliver 40 SP of work, so if your backlog is of 400 SP then we need 800 hours to complete it and 10 Sprints which gives idea on overall hours and timeline need to complete the project.

 

Hope this will help you estimating your Agile projects!