An Estimate is an Estimate … or is it?

Since the dawn of software projects, we software professional have been struggling with estimates. They are sometimes too large, mostly too small, and rarely bang on. We have tried to employee myriads of processes, controls, templates to it, but it doesn’t seem to get any better. When we say “an estimate is an estimate”, everyone seems to agree, but what gets acted on can be very different. I have observed this same phenomenon in a few different companies.

Development teams are asked to produce an estimate, sometime detailed, once all estimates are entered into a project schedule, it is now a “commitment”. It is frozen and any changes to it must go to a stringent change request process along with many stern stares, among other things. Does that sound familiar to you? Well, it is more common than I thought possible. Some of those companies are also agile shops. How can that be, you ask? The answer is, the management, and by extension the business, needs to plan out expenditure, resource allocation, etc. These all take time. So, companies always budget into the future. Shareholders and the board will make sure the executives are running the company in fiscally responsible manner. That means, when estimate percolates up to certain level, it will be seen as a promise. That is the reality of running a business.

Instead of getting into an argument over how to change the financial models of the world, being an agilist, I think about how we can adapt to it. Software organizations and teams must change their frame of mind when we are asked to provide detailed estimates, or in Scrum terms – set sprint plan, that we ARE making a commitment, rightly or wrongly. What’s important, POs and SMs take notice, is to control the scope and distraction so that the team have the best chance of adhering to it. That is also why, as a team, we should keep an eye on the sprint progress during every standup and an eye on the release/project progress during every retrospective!

The first benefit a decent agile implementation provides to any organization is visibility. The first hill to conquer though, IMHO,  should be predictability.

Patrick Li