When Estimates Go Wrong

I forgot to announce that ProjectManagement.com published my article, When Estimates Go Wrong, a couple weeks ago.

What is the Right Length for a Project?

I’ve seen many comments on the topic of estimation in the past year, and I’m starting to notice some trends and assumptions in them. One of the common assumptions is that, given a particular team and amount of resources, there is a correct length to a project. A twin to this one is that there is a correct estimate that contains the same end date as the subsequent actual project performance. (Continued)

Managing Risk With Estimates

Used with care, software development estimates can help you manage project risks. They let you peer into the future, though only as well as your current understanding allows. Estimating based on what you know is easy. Estimating based on what you know you don’t know is possible. Allowing for what you don’t know you don’t know is prudent.

Managing risk is a dynamic process. I’ve seen people document a risk in a “Risk Register” document and promptly ignore it. That’s not management. Instead, consider different ways a risk might be reduced in likelihood or consequence. When time or cost is of the essence, think about how you’ll determine what you can afford, and when you need to take a second-choice approach. (Continued)

Team Commitment

Most Scrum teams estimate their top priority stories, select those stories that add up to their historical velocity for their sprint backlog. Some teams simplify this by merely counting the stories, or using the mathematical reciprocal, cycle time. Others make it more complicated, calculating the effect of days off and other known distractions from the work.

However they calculate it, some people put a lot of faith in the historical data to guide the future. “It’s data,” they say, “it’s better than guesses and not subject to cognitive bias.” Not all data is easily measured and converted to numbers, though. Limiting yourself to this initial calculation is, itself, an example of anchoring bias. (Continued)

Estimation as Hypothesis

Experimentation is a powerful learning tool. When I was young, I performed scientific experiments by mixing chemicals together to see what they would do. I learned that most random concoctions from my chemistry set would make a brown liquid that was often hard to clean out of a test tube. I learned that sometimes they would create very smelly brown liquids. These were not really experiments, however, and I didn’t really learn from them. Instead, these were activities and I collected anecdotes and experiences from them.

The scientific method rests on the performance of experiments to confirm or deny a proposed hypothesis. Unless you can propose a hypothesis in advance, you cannot design an experiment to test it. Until you test the hypothesis, you haven’t really learned anything. (Continued)

How do we estimate?

There have been some web posts and twitter comments lately that suggest some people have a very narrow view of what techniques constitute an estimate. I take a larger view, that any projection of human work into the future is necessarily an approximation, and therefore an estimate.

I often tell people that the abbreviation of “estimate” is “guess.” I do this to remind people that they’re just estimates, not data. When observations and estimates disagree, you’d be prudent to trust the observations. When you don’t yet have any confirming or disproving observations, you should think about how much trust you put into the estimate. And think about how much risk you have if the estimate does not predict reality.

This does not mean, however, that you have to estimate by guessing. There are lots of ways to make an estimate more trustworthy. (Continued)

What Decision Are We Supporting?

In business, we’re often asked for estimates with too little context to understand the request. When that happens, we’re likely to expect the worst–that our estimate will be treated as a “guarantee not to exceed” and we’ll likely be in trouble at some time in the future. Of course we think that; we’ve been burned too many times in the past. Our fear of the consequences will encourage us to spend far too much time and effort trying to get the estimate “right” so we won’t be blamed.

If an estimate is really an estimate, then we know that it’s “wrong” in the sense that the subsequent actual reality is unlikely to equal it. The estimate is a guess, perhaps an educated guess, predicting the future. Predictions are hard, especially about the future.

Given these problems with estimates, why do we bother to make them at all? (Continued)

The Date Question

A common question heard in companies that produce software, either for in-house use or for sale, is “When will this software be done?” I’ve observed this question being asked when it was not yet decided what the software was to include, nor who was to build it. It’s clear that we have little on which to base an estimate, given this state of affairs. Nevertheless, in many organizations, people will start to anticipate what it will include and who will be available to build it in order to give an answer to this question.

Not everyone is so compliant, though. Some people will say that not only can you not estimate the construction with so little information, but you don’t need to estimate it. They’ll say it’s enough if you can build it in little increments of functionality, and stop when it does enough. (Continued)

A Big Estimate is Not a Sum of Small Estimates

I’m working with a client that has multiple, non-collocated component teams working on one project. It’s not my ideal situation, but we’re making the best we can of the situation.

We built a story map of business-oriented, project-level “epics.” These have been prioritized within business themes, and have been tentatively scheduled for development releases. The early ones have been estimated with level of effort (LOE). Basically these LOEs are Small, Medium, and Large, but given numeric scores to allow tracking project progress toward development releases from a business point of view using a burnup chart. (Continued)

Multi-Release Burnup

In my experience, Agile projects almost never have a single milestone at the end. The business wants to see multiple milestones along the way, taking internal releases from the development team even if they’re not prepared to make them public. The simplest dashboard I know to illustrate this situation is a burnup chart with multiple goal lines, indicating the goals of each milestone.

This sort of chart is trivial to create by hand or with a spreadsheet. The typical Agile Project Management software, while providing a myriad of ways to view data, never seems to include something as simple and powerful as this. Fortunately, it doesn’t take much time to create your own. It takes a few minutes at the end of each sprint to update the chart, and you can make sure that the data is correct as you do so.