What is the sense of estimating?

4 min readDec 15, 2020

Overview

Agile manifest speaks about planning the sprint and even says that task added to the sprint should be completed inside the iteration. Redundantly if you can not complete an issue inside the iteration you must to do it in the next one. It is a bit confuse. Isn’t it?

In order to aboard this problem, many Product Managers add to sprint tasks shorter than 2 weeks (or any other sprint duration) and split bigger ones in sub-tasks. Intuitively, to decide how many task include in a sprint we should know how complex is. Teams spend ours weekly to analyze each task and classify them in groups using different estimation methods.

Real examples

In an experience I had, the analyst was upset with me because I was not trying hard enough to make correct estimations. So, I decided to use the 5-why technique to find out why estimation was so important to her. I did to the third why question and she couldn’t answer. She just didn’t know why she did estimations.

Another curious experience is with the team I used to lead. I told them that they can organize their work as them prefer and they started to estimate tasks. I mean, estimations were optional and they decided to include an estimation meeting into the development flow.

I remember a boss who made me estimate to write the deadline in his calendar. He liked follow all activities in the calendar and he considered as a delay also one day. It was his way to organize activities.

Maybe, the answer witch most sense I had was from a software area manager in a development team for an internal customer. She implemented a methodology analyze-estimation-development in order to make a budget by product and also to let decide customer if want to go ahead with the task development.

The sense of estimate

In other industries or life situation, you estimate to make a decision. Before travel, you calculate the travel duration to decide witch route you prefer. Sometimes you choose a faster highway with tollbooth and in other cases a slower route without additional cost. You estimate to organize your roadmap to be better prepared to that situation. Certainly, you estimate when you do not know the place, when you travel occasionally or when your time is limited. But, I am sure you not estimate the time to arrival when you go to the supermarket, in a walking in a free day or when you have to do a route several times like going to your girlfriend’s house.

What does it means in the software industry? In some cases I find very useful estimate. It helps to measure and control the risk in a software project. Unfortunately, estimate is, in my opinion, another example of the availability heuristic, also known as availability bias. It means that estimate is a good practice, but we should use time carefully. The lack of synergy and communication are leading companies to spend more time in meetings. Like as the “real world”, estimation can help us to decide which is the better plan the future, but is a bad way to build it.

When to estimate

- When the selling product is hours instead a software (piecework, software house, consultancy)
- When there is an external deadline (a new law like GDPR)
- When estimation is used as a communication tool (like using effort as confirmation check)
- When there is a suspect that a task can involve many different teams, iterations, and other resources (like a big rework)
- When there is a decision made previously that has a direct effect on the task that is being analyzed (for example, adding a functionality that a third-party technology already purchased will take care of in the near future)
- When unexpected big events appear and there is the possibility of pivoting the project
- When the product lifecycle is a star

When NOT to estimate

- When the company business model is software as a service (SaaS)
- When the solution to be implemented is well known or a routine (like adding a new typical CRUD)
- When the time is infinite (Usually open-source software, personal projects)
- When the estimation result does not matter (like a political decision in a company of launching a new product)
- When the product lifecycle is a cow

Conclusion

The main goal of estimations is manage risk in order to get better prepared before work. Examples before are a guideline, not a rule. Estimation is not a poker planning or Fibonacci points (they are methos). Instead, estimation is an effort analysis to measure risk. Probably you will find exceptions to this guideline, but it should be aligned whith the 90% of situations.

Consider that estimation are optionals and you can work perfectly without them. Estimation, are… estimations! It is not a contract or a precise predict. In order to guarantee the fulfillment of the objectives, estimations must always have an alternative “Plan B”. It is only enough to use Timeboxing techniques.

But… how to do the sprint planning without estimate? How I know if a task is longer than 2 weeks? What about the Fibonacci points and productivity trend as KPI? We will answer them in the next article.

Sources