Skip the Estimates

In our company we use a large and complicated spreadsheet for estimating project size. We have designed the formulas to include frontend and backend features, number of deployments, min/max ranges, product layout, external interfaces, team size, project risks, biorhythms and planetary orbits. We've made the spreadsheet so complex that consultants are afraid to touch it. I even entertained the thought of adding sound effects to mimic a nuclear reactor.

Unfortunately, our scheme to prevent non-developers from making their own estimates has worked rather too well. Management told me that the estimates the system spews out are actually quite good. (And they aren't even radioactive.) But this means that our expert developers now spend way too much time making new estimates (which, on top of that, also need to be reviewed by peers), while I would rather see them doing something useful. Like writing code and building products.

So, I'm going to propose something new: skip the estimates!

Our developers spend hours calculating whether a project's size is 64.5 or 67.25 days. And suddenly I started thinking… who cares about this number? Certainly not me! Why not break all our projects up into only twelve fixed-size categories? Category X would be all 30-day projects. Category Y would contain all 50-day projects. Category Z would be all 80-day projects… Etc…

It takes an experienced developer to estimate a somewhat reliable project size. But I think any consultant with half a brain, and not too many beers, is able to tell whether a project is more likely te belong in the 30-days category or in the 50-days category. Does anybody really care whether it is actually 35.5 or 42.75 days? Just make it a 30-day or 50-day project, either is fine, and start the timebox! Because, whatever the "real" size, there are always two important principles applicable to any project:

  • You can apply the YAGNI-principle ("You Ain't Gonna Need It") to any project that is too big.
  • You can apply Parkinson's Law ("Work expands to fill the available space") to any project that is too small.

Et voilá, shut down the reactors! Problem solved!

Having only 12 categories of project sizes to choose from will enable our organization to streamline its operations. We can standardize on methods and planning per project category. And our development experts can do what they do best: writing code and building products.

Best of all… we can now sell our spreadsheet to Iran or North-Korea.

  • We Underestimate Nonlinearity, Not Effort
  • Don't Believe Anyone
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”