Decomposition

If you don’t have data that’s similar enough to the whole project, then perhaps you have data that’s similar enough to parts of it. If the project being estimated is really large, then it becomes difficult to compare, anyway. This is generally true in estimation of all sorts. You can judge if two cardboard boxes are approximately the same size, but you might be hard-pressed to tell if two counties are. We lose our perspective when the thing to be estimated is larger than we can view or imagine all at once.

If you break it down into pieces, then there’s more likelihood of those pieces being similar to pieces of other projects: “The reporting for this project is similar to the reporting we did last year. And the user interface looks about the same size and complication as the project we just finished.”

When I had little experience in software development, I fell back on decomposition as my primary estimation tool. I would take the large chunk of work that I was estimating and imagine doing it as a number of small pieces of work. If these pieces were small enough, I could imagine how long it might take me to accomplish each of them. Then it was a simple matter of adding them up to get my large chunk estimate. This always gave me a number to report, and sometimes that number was useful.

When you consider breaking the work down into smaller pieces to estimate, you open a whole new can of worms. How you break it down depends on who breaks it down. It depends on their understanding of the problem being solved and the possible ways of solving it. Different decompositions can lead us in entirely different directions. And there are many ways in which you can fool yourself. We’ll look at the details of this in Chapter 3, ​Decomposition for Estimation​.

What do you do when you have no appropriate analogs for the upcoming work, whether or not you decompose it into smaller pieces?