Estimation Can't Be A Number Only

This blog is not about the specific how around different estimation methods. This is about what you should expect from an estimation and how can you support the team to help you make better informed decsions.

Estimation is an critical step of project planning and it can be valuable if you use it for right purpose.

Before we do the deep dive, let’s look at a few scenarios and see if you are familiar with those:

Scenario 1: Will multi-rounds of estimation get you better estimation?

Every year May - June, it’s the yearly project planning cycle because of annual budget cycle. Team A is asked to estimate a piece of work, it takes 2 weeks for the team to finish the estimation. After the results shared back with management, the feedback is the estimation is too big. Thus the team needs to re-estimate. In the end, after 4 rounds of estimation (8 weeks of team effort), the management is finally satisfied after the team submitted an estimation which is 1/2 of the orginal estimation.

Scenario 2: Project keeps delaying and the root cause is estimation?

Team A started to work on the project, yet in execution, the project keeps delaying and business owner becomes extremely unhappy with the team and starts to blame the estimation.

Scenario 3: Is estimation a commitment?

Peter is the project manager for Team A’s project, obviously under high pressure due to the delayed timeline. His day job has now becoming tracking the completion time of a story and estimation, ask the team to work overtime if they can’t keep the orginal.

Developers starts to talk to each other about they need to double/triple the estimation next time. Some of the team also become active in job seeking.

What is estimation?

Among all the defitions, this one is my favorite as it tells the truth about what your expectation should be.

Estimation is the fine art of guessing per Wikipedia.

An informal estimate when little information is available is called a “guesstimate”.

What does estimation tell you?

What estimation is telling you is really about a snapshot of people’s best guessing at that given time.

• The gap between the knowledge of estimators and the project that is under estimated

• The confidence level of the estimator

• It’s not about accuracy, it’s about consistency

• It’s relative

• It’s about the thumb rules of estimation of the team

• The risk level

• The assumptions of way of working, engineering/delivery practices

• The dependencies

• Shape of the work

How should we treat estimation?

In practice, we tend to treat estimation in the way assuming it’s objective and accurate, yet it’s not.

So let’s treat estimation like it is, bring the subjective factors back to estimation. We should focus more on consistency over accuracy, focus on the movement of the non-number part of estimation outcome.

Anti-patterns observed

Here is a list of few anti-patterns observed:

• No baseline of estimation
• Work is estimated separately via silos
• No shared understanding of way of working before estimate
• The work is too high level to estimate
• The people who estimated the work is not the team who will deliver the work
• Estimate as an individual rather than team
• Does not track the non-number outcome of the estimation process
• Mixed estimation process with release plan process
• Treat estimation as commitment