Should we expect estimates for software development?
There’s a movement called “No Estimates” that suggests there is a better way to develop software without using estimates as part of the process. In an interview with InfoQ, Woody Zuill states, “Personally for me, what No Estimates is about, is alternative ways to make decisions, that don’t require that we use estimates.” As I read various articles on the idea, they suggest that the need for estimates is reduced (or eliminated?) by incrementally providing working software that can be shipped or delivered to the customer. The counter argument says that estimates are needed to provide input to scheduling, budgeting, and prioritization activities..
I read the debate with great interest since software delivery and estimates are part of my everyday life. I think proponents of both sides would agree to that the business of writing software is non-repetitive and could be classified as art. Estimates by definition are not completely accurate. In my mind, the dilemma between the programmer and stakeholder is not only how the estimates are delivered, but how they are interpreted by each. Project stakeholders look for estimates to provide working accountability for schedules and budgets. While the programmer is just trying to give a forecast of what he or she thinks based on what they know at the time.
The answer isn’t whether we estimate or not, but why we estimate.
Zuill continues his thought, “But the problem isn’t with how easy they are to do, or how accurate they are. Is has more to do with, why do we need the estimates. What is our motivation for having these estimates?”
It’s a fair question and a good one. The value of getting the answer lies with discussing this line of questioning with project stakeholders to come to a mutually acceptable answer. Completely getting rid of estimates is hard because estimates are part of our life and culture. It spans all industries and services. We use estimates for our personal possessions as well as business processes at work to help us make decisions. Zuill asks if we need the estimate to make the decision.
Think about the first principle in the agile manifesto that says “Individuals and interactions over processes and tools.”
You see the value in the estimate is the interaction it creates with the customer and other project stakeholders. Estimating could be a nuisance to the programmer, but estimating creates an opportunity for an interaction with an individual. Customers like and expect estimates. But I think many customers and stakeholders would be open to the question of “What value does this estimate provide?” What we may find is that some estimating steps could be eliminated while others should remain. The answer may be in the middle-ground. Software development, after all, is a custom build each time through.