There I said it. I like estimates. I like estimating. I think they provide value to my team and the customers. I will attempt to explain why is this Blog post.
1) Estimates make me think through a solution
I liken estimating to the visualization successful sport athletes do. It is the visualization and mental practice of what is likely to happen. Great athletes use this practice to anticipate issues and try to make every game as successful as possible.
When I estimate I am forced to examine project details and technology and think through the deliverables at a detail level and how we would build them. This helps to identify issues early and give the team and client lead time to decide on a resolution. When you discover issues late in the game, your options are limited and client anger usually follows.
If we just start building without doing detailed design and planning, the chance of project issues increase. I agree that you can do that detailed design and planning without estimating, but due to how estimates are used traditionally they result in people doing more detailed design and planning. This is because people know they are used for financial decisions and require some level of certainty. Estimates matter.
Now I don’t subscribe to estimates being used as promises and never being able to update the estimates. In fact, project estimates need to be updated weekly as new facts are encountered. This frequent updating of estimates needs to be discussed and agreed to before the project starts. Clients need to agree estimates are estimates, not promises or actuals.
2) Estimates create a shared understanding
One may disagree on the value of estimates. But I think everyone agrees that the discussions that occur while estimating are invaluable. These discussions create a shared understanding throughout the entire team. Yes I am assuming you are estimating with your entire team. If you are creating estimates for others then you have bigger problems than just estimates.
3) Estimates allow the clients to validate Minimum Viable Product before we start
Although the No Estimates approach and Story Slicing will allow the clients to have input and control over the work as it proceeds, it is still possible to start a project without the ability to complete a Minimum Viable Product with the available budget. Once you discover you can not deliver the required functionality, you may have wasted considerable budget. It is recommended that projects should not be started that have such a small profit margin. The reality is that most Information Technology projects have a small profit margin.
Will estimating Minimum Viable Product provide a iron-clad solution to this? Definitely no, we will estimate incorrectly at times. But as stated in point 1. The process of thinking through the problem does increase the chances of success.
4) Estimates allow Clients to allocate post Minimum Viable Product budget to other initiatives
In addition, the clients may want to allocate some of the post Minimum Viable Product budget to other initiatives and not to wait to see how a project goes just in case the project needs it. Clients are not going to reserve large budgets just in case an Information Technology project need it. Clients have a very limited budget and there are always more initiatives than budget. Allowing clients just to stop projects at any point does not recognize the lost opportunity cost by not starting additional initiatives that could have placed them ahead of their competitors.
One can even say that while No Estimates works well for one project, it doesn’t allow for the discussions and trade-offs required to manage a large portfolio of projects where the clients need to maximize the number of Minimum Viable Products delivered each quarter.
These are my reasons as to why I like estimates. It should be noted that I don’t recommend doing detailed estimates in any way shape or form. These estimates should be higher-level estimates that are:
1) At a deliverable level
2) Can be updated every week
3) Are created by the developers and clients