The "Estimate" Problem

Prediction is very difficult, especially if it's about the future. ~Danish Proverb

There has been a lot written on estimates over past few years especially as the #NoEstimates conversation has gained popularity. I have also written a bit on this topic so I can appreciate any “estimate article fatigue” that may exist. The fact that people keep writing and talking about it is an indicator that there is some opportunity for improvement.

In most businesses, we need to answers to the following questions about the future:

• What will I get?
• When will I get it?
• What will it cost?

For example, when you take your car in for an oil change, what you get is the oil change, when you get it is whatever time they tell you to come pick your car up and what it costs you is whatever the cost of the oil change happens to be.

So businesses need estimates in order to plan and make decisions. Remember, software development is often only one of several activities in a businesses value stream.

And while it is true that estimates are often needed, it is equally true that it is extremely helpful if stakeholders understand the challenges associated with software development estimates. Why?  Let me explain.

Software development is predominantly a process of discovery - discovering both what solutions needs to be developed and how these solutions will be developed. It is akin to creating a new recipe for a new dish or composing a new piece of music for a special event like a wedding.  Or writing a book. Or developing a new marketing campaign.  Or developing the design for a new vehicle.  I'm sure you get the point.

While we might have a good idea on what needs to be done (some list of requirements or something similar) when we ask for estimates, the fact of the matter is that new “what’s” emerge while we're actually developing software.  Some refer to this as scope creep but I think it’s more appropriate to consider this phenomenon to simply be "learning as we go". It is very rare that we anticipate everything that will be required to provide a satisfactory solution.

For example, let’s say the software initiative decomposes into 100 distinct work items and maybe you have data that gives you a range of how long it takes for your team to complete 100 items, are you able to guarantee that the number of distinct work items will stay at 100? Can you predict how the addition or subtraction of work items will impact your timelines?  Some organizations resort to “freezing requirements”. Does this practices give your organization a competitive advantage?

Not only is the "what" subject to change, as a team, we still need to figure out how we will accomplish the what. Most of this “figuring out” happens while we are actually doing the work.  Spend a day observing any team that has the responsibility of developing software.  I’m positive that the amount of rich dialogue on “how” they are developing the solution, will not escape your attention.

The uncertainty around the “what” and “how” make obtaining highly accurate estimates for software development initiatives especially challenging. (This is untrue if we’re in the business of solving the same business problems over and over again.) Estimation is actually quite easy. Providing estimates that are valuable, meaningful and will be used appropriately is where all the fun is.

Now all would be fine and dandy if all the stakeholders involved in software development understood the challenges with software initiative estimates.  However, it seems that shared understanding is severely lacking in most organizations.  Too often leaders (including technology leaders) throughout the organization interpret estimates as actuals, targets and commitments and then subsequently hold teams accountable if they don’t come in at their estimates. Every week on social media, I read stories of teams that are no longer being transparent about what they can accomplish because of how estimates are being used to punish them.  

I believe that coming to shared understanding is how we make progress on this problem. I believe that it’s the responsibility of software leaders to create the room for dialogue with other leaders in the organization. Dialogue should be centered on the challenges of software development estimates and how those estimates should be used responsibly.

To be fair, we could spend time, even significant time, trying to reduce uncertainty and ‘unknown unknowns’ in software development initiatives so as to provide accurate estimates but at this point we’ve begun to actually do the work. Depending on the decisions that need to be made, this might be the right thing to do. Does the value of the information created by spending significant time, justify itself? This is the question that would need to be answered.

So what can we do to exploit the realities of software development estimates? Here are a few thoughts that deserve deeper exploration:

• Form teams of people committed to mission with team members who know what to do. Best efforts are simply not enough ~Deming.  
• Be explicit about real business deadlines. Don’t use false dates to create urgency as doing so eventually breeds apathy.
• Use estimate ranges to communicate the uncertainty present in the initiative. Remember, the map is not the territory ~ Alfred Korzybski.
• Adopt iterative and incremental approaches to developing software.  Bite small, chew fast.
• Continuously plan as no plan survives contact with the enemy ~Helmut van Moltke.
• Guide software development progress focusing first on business results and then the artifacts that are being created by the process.

What are your thoughts on this problem? Join the conversation in a constructive manner and let's see how we can improve the state of things.