Stepping Back for a Broader View

Software development estimation routinely depends on comparison to past experience, either your own or someone else’s experience that has been documented. Either way, the experience won’t be a direct comparison, because no two software development projects are exactly alike. There’s no need to produce the exact same system and, if you were to do that, it would be a different experience because it would be informed by having done it before. There are too many variables to expect an exact match, but there is plenty of opportunity for success if you have reasonable expectations about accuracy and precision.

Some questions you might consider as you’re making such a comparison include:

• What aspects of this system are the same as the reference experience? What aspects are different?

• How does the context of this system resemble the context of my past experience? How does it differ?

• What is similar to past experience about how we’re going to develop this system? What is different?

• How sure am I of the details of the past experience that I’m using for reference? What might be missing or misremembered?

Don’t forget that these initial estimates are still estimates. They can be used to make decisions, but don’t trust them too far. For accuracy, you’ll want to track your progress and compare it to your initial estimate. In order to do that, you’ll need to decompose the work into smaller chunks, even if you were able to come up with a total estimate without doing so.

There’s a number of ways to split up the work, and they have different advantages and disadvantages. In the next chapter, let’s look at the alternatives and the potential gotchas when decomposing the work.