Estimation : What, Why and How ?

7 min readMay 3, 2022

Estimations are approximate. Well, but still not like above. ( ImageCredit — *https://xkcd.com/612/*)

Estimations are tricky business. Why do we call estimates as estimates because they are always approximations, they never really can be taken as a sure shot fact to derive any of the plans. It basically gives us a pathway to build those plans and make certain commitments.

In terms of building a software , Estimation is an important process where the development team comes together and estimates the time it would take them to build a certain feature, release a product etc. Estimations are usually done in story points, days or hours.

While estimating, team makes certain assumptions, considering success and failure scenarios along with a multitude of other factors like feature clarity and skills maturity of the team etc. to derive the estimates. Eventually simply stated, Estimate

Is relative and Approximate.
Is Not Absolute and Final.

Why do we need estimates?

As we figured out above, estimates are not certain and are bound to change. Then a question pops up — Why do we really need them? We need them for sure and the answer to that is below.

We estimate because

It provides us a way to calculate how much time a feature may take to complete
It allow us to do planning — both short term and long term planning
It provides the inputs so as to forecast future milestones and plan future events.
It also provides a way for businesses to determine the cost of building a feature.

When do we need to estimate

Estimates are almost required at almost each stage of the Product life cycle for planning purposes.

To understand different stages in Agile Planning, have a look at Planning Onion as that would help understand what is expected during each stage and which estimation technique would be best suited at a particular stage.

Strategy Planning Stage

Organisation designs and develops the route map on ways to attain the desired goals. Usually has a span of around 3 to 5 years

Portfolio Planning Stage

Developing a set of products that align with the strategic objectives of the organisation

Product Planning Stage

Plans for the number of releases of a specific product. It’s in alignment with the portfolio stage

Release Planning Stage

Plans for the forthcoming release of a product and is in the thread to the product plan

Iteration Planning Stage

Teams Plan their work considering the release Plan

Daily Planning Stage

Teams decide on the day-to-day tasks to be executed

Estimation Techniques

In the last section, we saw different stages in Agile Planning. In this section, I am going to discuss different techniques used for estimates. These techniques would be more suited when applied during — Release Planning, Iteration Planning and Daily Planning Stage of the Planning Onion.

Planning Poker

Planning Poker technique is generally employed when a team is at the implementation stage of the feature and is the most widely estimation technique by agile teams.

One person moderates and explain the story to the team
Team considers and discuss the tasks which would be needed to complete the story
Estimation can be done in both days/ story points / hours.
Estimation includes all work that needs to be completed in story to mark this as done
Each person in team estimates and estimates are revealed together to avoid any bias, influence of folks revealing estimates prior
If there is consensus, an estimate is written against the card else the team discusses the differences and gets to a consensus.
This exercise is repeated for all cards team plans to complete for that feature.

T-shirt sizing

T-Shirt Sizing is a relative estimation technique which can be employed to estimate a large number of times in a smaller time frame. This is also useful when a team is new and does not have a defined velocity. This technique also comes in handy during Release planning.

Consider the T-Shirt sizes that the team would be using for estimation — XS, S, M, L, XL.
Facilitator would explain stories and ask for any queries.
Each team member gives a T-shirt size
Team raises their card simultaneously
For any differences in estimates, the team would discuss and then come to a consensus similar to Planning Poker.
Eventually if the team wants they can assign story points at the end of the exercise.
Team can also have a reference story to map what XS,S, M…

Bucket System

Bucket System Estimation technique is used when there is a very large number of items to be estimated with a medium to big sized group of people, and to do it quickly.

It is a collaborative technique with the Divide and conquer approach.
Team chooses a random card and places it under one of buckets. This card becomes a reference card.
Then the group picks another card and place in a relative bucket to first card
Similar exercise is done for the 3rd card.
After picking up 3 cards, if any adjustments are required in bucketing these cards, it is done and these become reference points for the rest of the cards.
Then all cards are divided amongst each member to place them in appropriate buckets.
Once all cards are done, group performs a sanity
If any member does not agree with the bucket, then can bring in the attention of the group and it is discussed in the group to form a consensus.

The Silent estimation

Planning Poker takes a long time to estimate and may not necessarily work when estimating a large set of stories. Silent estimation can be used there to estimate stories in minutes.

Team needs to decide on a scale to use for user story point sizes
User stories should be placed somewhere visible and easily accessible so a smooth flow can be established.
Choose and agree a mid-size user story for starting off.
This is the benchmark against which the first few user stories will be compared.
After that, people will size the current user story against all currently sized user stories.
If a story is moved around with different members estimating, then it can be moved to the parking lot for later discussion.

The way this technique is different from others explained till now is that it is done silently which shall be ensured by the facilitator. So team members who are not very expressive also feel free to state their thoughts by moving the cards and making their opinion clear to the group.

3-Point estimation

3-Point Estimation is a useful method when teams are new, there are frequent cases of over / under estimating work and can also be used in early stage estimation.

Factors in best , worst and most likely scenarios while estimating
Team preempt blockers , boundary conditions etc.
Determines O (optimistic), P ( Pessimistic), M(Most Likely) estimates
Then Averages can be calculated as below

Triangular average = (O+P+M)/ 3

Beta average = (O+P+4M)/ 6

Beta Average is more widely used under this method as it comes in closest to expected value.

When to use which Technique

Now we have learned different techniques to estimate, it is time to get to action and see which technique would apply where. I have pointed out while describing above techniques , where and when which techniques could be applied. I leave with you few scenarios to think about

New Teams
Established teams
Large Unestimated Product Backlog
Unknowns on Feature Clarity

More than 1 technique can apply to each of the above scenarios. Feel free to add your mapping in the comments section.

Estimation Pitfalls

While we know that estimates are approximations , we can still have a reasonable chance of success if we avoid some frequent pitfalls seen with estimations. I have added a few of those below here.

The larger the estimate, the greater the risk it is wrong.
Vying for accuracy, not understanding estimates would always be approximate
Always working on Epic level stories
No clear vision / objectives / development approach
Rushing for estimates
Master Story list is big and would take weeks to estimate, implying, we are estimating too much , too early
Failure to assess risk and uncertainty.

Estimation best practices

Fostering culture of trust and empathy in the team
Estimate as a team — people who are going to work should estimate
Definition of ready ( minimum details for estimation) and done should be clear
Presenting estimations as a range
Apply Non Linear Sequence for estimation — 1,2,3,5,8….
Embrace Reality — refactoring code base v protecting future velocity — basically considering the need of taking right actions and decisions.

In continuation to this blog, I would reflect upon estimating in story points v estimating in days in the next blog on Estimations.