In a "Traditional"  approach to estimation a set of detailed requirements are analyzed, and from that analysis a solution is designed that will fullfill these requiments. We then estimate the time it will take for us to build that design.

If we do Agile development, we instead measure the relative size of each of a set of high-level requirements (e.g. in the form of User Stories). We then assign a conversion factor to the relative sizes of the User Stories, to be able to predict, when we can have what done. If we do not know how long time it takes, we can do a small iteration, and see how much we are able to complete in e.g. a week. We then use that knowledge to extrapolate from the whole set of requirements, to arrive at a delivery date.

If I am to choose from those two methods, I will greatly recommend the latter. simply because the detailed analysis and design, always misses something, and because it has an underlying assumption that nothing, or very little will be changed over the course of the project - thus the investment in the detailed analysis and design is justified. Anyone who has created software in the real world know that is never the case.

But both approaches treat estimation, as if the size of a piece of functionality or time it will take to complete it, is a real characteristic of the feature, and what we do in estimation is trying to find that hidden, true number.

I will call both these approaches Reactive estimation.


And off course there is something I will call  Proactive estimation. In this kind of estimation, the estimators acknowledge that creating a piece of software, is a creative process, where problems are solved on a daily basis, and that the level of teamwork, dedication, creativity and problem-solving skills are the factors that really determine the lenght of a software schedule. In this kind of thinking, a team will commit to deliver a product to a certain date, but they know, that what will be delivered, will depend on their ability to learn and solve problems along the way. The development process is then organized to accelerate learning, and plan  in a way that keeps decisions  open as long as possible. In that way the team will arrive at the best possible result at the given date.  Much the same way a play normally always will have premiere at the date that was planned months of even years earlier.

Does this sound to crazy to you? Maybe - but that is the way Toyota creates new cars, on time and with fewer resources than their competitors, and I am convinced that some kind of proactive estimation was used when the iPod and the iPhone was created.

By Bent Jensen