Agile Estimating – Why Bother? | David Tzemach

One of the hottest topics in Agile projects is whether Agile teams should estimate their work at all in an environment of short development cycles with a low margin of error. I have posted this question a couple of times to Agile teams and project managers to try and understand why this question is even asked.

The answers I received differ between stakeholders, project managers, and Product Owners. Remember, the PO has the closest interaction with the customer who provides answers like “we must estimate as it’s an essential part of the project” or “A customer's not going to sign the contract without guaranteeing delivery dates”.

However, the answers I received from development teams doing the estimation and product delivery were utterly different. Answers like “estimation is a complete waste of time” or “we keep investing time in a process that just holds us back from doing the actual work”, or “why should we even attempt estimating in the first place?”.

I expect that the answers from the PO/PM do not surprise you at all. It is just a hypothesis that stakeholders representing the management side will want to know the deadlines without compromising on the estimation process. From their perspective, the team should estimate their work to understand what to expect within a specific period (from their side, the estimation process is not questionable).

The complexity starts with the answers I received from the development teams. I’m a great believer in estimating and teaching it to all the teams I work with. That makes it even more interesting for me to understand why estimations have such a negative reputation among development teams.

Although I heard many reasons why estimating is a waste of time, I found one that exceeded them all. The fear of failure due to negative past experiences. You see, many teams that start working in the Agile environment aren’t any better with Agile estimating (relative estimates) than they are with traditional estimating. I think this is the main reason for teams to reject the idea of estimating entirely.

Suppose Agile estimating presents an entirely new approach to estimating, which is supposed to fix everything related to traditional estimating but still doesn’t work any better. Why should we keep failing and waste time on estimating at all? If you have ever tried to stand in front of your team to explain why they are wrong, you should know that they push back. You see, the key resides in the team understanding that estimating is not about estimating at all.

The true meaning of estimating is creating a shared understanding of the requirements, the challenges involved in the development process, and the solution.

Changing the mindset of your team regarding estimating starts with your understanding that whenever your teams have problems estimating, it’s usually not an estimating problem; it’s a collective problem rooted in the team. If you fix this, the chances are that you will fix your estimation problem too.

Joint problems can result from numerous causes such as low-quality stories that do not provide all the information needed for conducting the estimating process, insufficient understanding of the business problem, technical debt, and of course, the fear of not delivering on time.

Joint problems increase the frustration of the team, who end up committing to the sprint without sufficient understanding of what they are supposed to build, what work needs to be done or how they are going to do it. This, of course, leads to missed deliverables and teams that become frustrated with estimating.

That said, giving up estimates is rarely an option as they provide the business with an idea of what deliverables they will get and when they will get it (roughly).

My opinion is that you cannot give up estimating, as I have never seen a project succeed without it. The key is to help your teams understand the value and importance of their estimates and remove the joint problems that hold them back from really succeeding in the estimating process.