Estimation means “approximation”, it could be predicting about Time, Cost, Effort or anything else. In a typical project or product development, whenever the team starts working, the very first question is “By when it will be completed? Or “How much work will be completed by a given date”. Important point to be remembered is, there is no accurate estimate, it is an oxymoron. When estimation meaning itself is “approximation” how can someone estimate accurately?

There are many techniques used in traditional project/product development but in Agile all those methods may not work due to the uncertainty, unknown factors and continuously evolving requirements. As long as “it is okay to be roughly accurate rather than precisely wrong” you can use any estimation technique in Agile projects. 

This article helps you explore some Agile estimation techniques.

Affinity estimation Technique: 

This is also called the “bucketing” method. This method can be used at the “Release Planning” to come up with a rough estimate for the release. In Affinity estimation, the Product Owner and the Developers of Scrum Teams (optionally any subject matter experts or stakeholders) participate to arrive at the estimation. There will be 3 steps in Affinity Estimation method as described below:

Step 1: Silent Sizing based on relative comparison:

On a wall, first a horizontal scale is chosen with a wider distance. On the extreme left side you write “Tiny” and on the extreme right side you write “Giant” and in between you keep “Small”, “Medium”, Large”, “Big” with equal distance. 

The product owner then provides the Product Backlog Items (may be user stories) to the team(s) which are probable candidates for the upcoming release. 

Each Developer (Team member) estimates their story solely silently without any conversation or discussion with other members. Based on their estimation, everyone places the user story at the appropriate location on the scale, anywhere between “Tiny” and “Giant” as per their understanding.

Step 2: Adjusting the Estimates

Once each user story is placed on the scale, team members edit the relative sizes on the wall by discussing the story with each other about its design, implementation or any technical challenges. They also take inputs from the Product Owner for any queries about the USer Stories.  Based on the collective understanding gained during the discussion, the teams rearrange the user stories on the scale if required.

Step 3: Sizing based on bucketing 

The scale “Tiny” to “Giant” is divided and marked appropriately with the markers or paper tape of XS, S, M, L, XL, XXL and so on. Each bucket will be given a size number such as 2, 5, 8, 13 and so on. Teams now place their stories, which were on scale “Tiny” to “Giant”, to the appropriate bucket of the converted scale. They may have a collaborative discussion during this session.

Story point Estimation:

This can be used at the Sprint level during the execution of the Project. As the affinity level estimation is done at the high level during the Release planning, there may be items with large size that are ambiguous. So in order to have confident estimates, during the Product Backlog Refinement or the Sprint Planning, the Developers of the Scrum Team(s) will discuss with the Product Owner and try to split large items into smaller and provide estimates using Story Points. 

Story Point estimation process is as follows:

  • Based on complexity, uncertainty and volume of work involved, the team selects a smaller item and give a size like 2 or 3 Story Points
  • Comparing to that they try to select little bigger item in the Product Backlog and provide the size. For example for the first reference if the team gives 2 Story points and if the second item is roughly 4 times bigger than the first item, then they give 8 story points to the second item
  • Keeping the 2 items as reference they estimate the remaining items in the Product Backlog
  • They use modified Fibonacci sequence (0, ½. 1, 2, 3, 5, 8, 13, 20, 40, 100, …) for the estimation

T-shirt sizing:

T Shirt sizing is also similar to the Story Point estimation and can be used at the Sprint level during the project execution. The process is as follows

  • Create some reference activities like Front end work, Database work, external interfaces involved, coding, testing, and any other criteria required to complete an item
  • Decide the Sizes such as XS (extra Small), S (Small), M (Medium), L (Large) etc
  • Get same level of understanding on what XS, S, M or L means to everyone by discussing the criteria mentioned in the first bullet point above
  • Let the Product owner explains the Product Backlog Items to the Developers
  • Developers will ask queries to Product Owner to get clarity
  • Product Owner answers those queries
  • Then the Developers collaboratively discuss and identify the size for the Product Backlog Item
  • They may try to Split the large items into smaller so that their estimates can be more confident

Team half-day Estimation:

This is not a very popular technique but I have used it in some of my Scrum Teams. The process is as follows:

  • In this method, the basic unit of estimate is “Team’s Half Day” (THD). They arrive at the total number of THDs during the Sprint planning by removing the public holidays and personal time offs of the Team members
  • One Team Half Day consists of the half day of the Programmers, Testers, Front End Developers, Database Developers and any other
  • In the Sprint Planning, they calculate the Total Team Half Days available for that Sprint
  • They also provide the estimates to the Product Backlog Items with THDs like 2 THDs or 5 THDs and so on based on the complexity, uncertainty and effort needed to complete that item
  • In the Sprint Planning, the Developers select the items that will fill the available Team Half Days count for that Sprint
  • For example if for the current Sprint there are 25 THDs, then they may take items to fill that 25 THDs such as one item with 1 THD, two item with 3 THDs, two items of 5 THDs and two item of 4 THDs 

Tips to make estimation to be effective:

  1. Let all the Developers of your Scrum Team(s) participate in the estimation
  2. Let the Developers ask questions to the Product Owner to get clarity on the User Stories
  3. For the reference story size, everyone should have same level of understanding
  4. Let the estimates given through consensus
  5. Discuss the outliers in every round so that they can uncover hidden information related to complexity, uncertainty or volume of work
  6. Try to split large items into smaller before estimating
  7. If estimation is difficult, then run a spyke before estimating
  8. Timebox the estimation process