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 some guarantee of delivery dates”.
However, the answers I received from development teams actually doing the estimation and product delivery were completely 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 an axiom that stakeholders representing the management side will want to know the deadlines without the need to compromise on the estimation process. From their perspective the team should estimate their work so they can know 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. Personally, I’m a great believer in estimating and teach 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 for why estimating is a waste of time, I found one that exceeded them all. The fear of failure due to negative past experience. 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.
If Agile estimating presents a completely 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 try to explain why they are wrong, you should know that they just 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, of the challenges involved in the development process and of the solution.
Changing the mindset of your team regarding estimating starts with your own 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.
Collective 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.
Collective 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 actually 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 almost never an option as they provide the business an idea of what deliverables they are going to get and when they are going to 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 collective problems that hold them back from really succeeding in the estimating process.