I’ve written a lot about the challenges of estimates, which may have given the impression that I think they’re useless.

They aren’t. Well, not entirely anyway. I think the process of creating estimates is incredibly valuable.

Let’s look at all the things we have to think about when creating an estimate:

• What is the complexity of the work?
• What are the dependencies for the overall work?
• What are the dependencies for the specific tasks in the work?
• How much of the work can be parallelized?
• Do we have enough staff to maximize parallelization?
• What communication overhead do we have with the staff we want to deploy?
• Do we have the expertise in house to handle all the specific tasks?

All of these questions should have some semblance of an answer before a project is even started. You may not have great answers, but you’ll have at least an order of magnitude or better.

Is this a 3 month project for 2-3 people? Or is it going to take at least a year for 20? Can we even put 20 people on the project right away or does some foundational work need to be done by a smaller team before more people can be put on effectively?

Most people think bigger projects should be broken up into smaller ones. I agree. But you need to have some semblance of a plan to figure out how to break the project up effectively. Breaking up a project into smaller JIRA tickets where each ticket can only every be deployed internally doesn’t do any good other than shift work around in your tickets.

I have made that mistake in the past. We did all this planning and had what seemed like a very reasonable release schedule for internal use. After a year of development, we started collecting feedback from users with demos. A lot of our original assumptions were proven false and a lot of iterations needed to be made to get the product to a point where people were excited to actually buy it. That took another two years to get traction. Part of that was because we built too many assumptions in our software architecture. Making software “extensible” usually means extensible within a certain set of parameters, not a wholesale refactor of the foundations.

Breaking up a project into incremental public releases where you can collect feedback from users gives you data and context to refine the rest of the project (and your estimates). Understanding the project’s dependencies gives you the foundation for being able to make better decisions when that feedback comes in.

Most importantly, software estimates give you a better understanding of the costs of a project. Is this project going to cost us $100k? $1 million? $10 million? The exact amount fluctuates with the estimate, but the order of magnitude alone is invaluable when deciding whether something is worth building or not.

I was once at a company where management rushed the planning process and decided to take on a project that they thought was going to take 2 people 3 months. As the project kept getting delayed, they just allocated more developers and kept the project going week after week with no clue on when the end would be. 6 months after the original due date, we had used up the time of almost two dozen developers for a release that provided little value to our customers (and consequently little value to us).

Estimates do not need to be 100% accurate to provide value. For this particular project, the very act of creating a good faith estimate would have made it clear the project was not worth doing. We wouldn’t have known if it was a 6 month project for 20 people or a 12 month project, but we most certainly would have known it wasn’t a 3 month project for 2 people. Creating an estimate would have let us know that there were better uses for our time.

One of my favorite quotes of all time: “Plans are worthless, but planning is everything”