Accommodating the Unexpected

As I write this, much of the world is in a state of disarray. Many businesses are shut down for fear of spreading the Covid-19 virus, and others have suddenly switched to distributed work over the internet. Most software developers are working in physical isolation. Even those accustomed to working remotely are reporting that the current situation is affecting their ability to get things done.

I think it is safe to say that no software development organization expected this to happen. No IT department accounted for the disruption in their estimates and plans. While epidemiologists could predict that there would eventually be a worldwide pandemic, even they could not predict the severity or timing of such a disruption.

How has this affected your work? Are you still expecting to meet the plans made before this happened? Have you given up planning altogether, just trying to get something, anything, done? Or have you looked at how things have been progressing in the last 2 or 3 months and adjusted your expectations?

(Continued)

Estimating in Comparison to Past Experience

The simplest method of estimation is to compare the anticipated work to past experience. And we all have experience that we can use. The big question is how relevant is that experience. A secondary question is how clearly do we remember that experience.

We always have experience, of course. We weren’t born developing systems. We’ve tried things, and learned things, from childhood onwards along a path that’s lead us to today’s situation. In all the things we’ve done, there’s something that we can compare with the work we’re facing. (Continued)

I’m late, I’m late!

Even when you’ve done something many times before, sometimes you forget something or make a mistake.

This morning I was on my way to visit a client and realized I’d forgotten something. It seemed to me important enough to do something about it, so I went back home and got it. The unanticipated delay threw my schedule into disarray. I wasn’t going to arrive by the time I wanted. I was frustrated and unhappy with myself.

I see similar things happen all the time in software development projects. Something throws off the schedule. People get unhappy. (Continued)

Framing the Question

“I need this project done by date D and within cost budget C. Now calculate an estimate on the project.”

A friend of mine used this example to illustrate anchoring bias in estimation. Note, however, that he doesn’t make the question explicit. Further conversation revealed that he had in mind that the date and cost should be the output of the estimation. With that assumption, that statement preceding the request will definitely anchor the answer, and realizing that this bias is likely will call into question whatever estimate is given.

Given the stated need, however, I would reframe the call for an estimate from “When will this project be done and how much will it cost” to “What is the likelihood that the project can be done within these constraints?” (Continued)

Ways of expressing estimates

The way we express our estimates color both the way we think about the thing being estimated and the way our estimates are heard. (Continued)

Another Two Sides to Estimation

There are many ways to look at the issue of estimation. Everyone in the business of software development has had experience with wanting estimates, being asked for estimates, or both. That experience frames how they look at the issue. A considerable share of those experiences have been painful. I dare say that everyone in the business has had some painful experiences around estimation, and the painful ones seem to stick in our memory more vividly than the benign ones.

What makes these experiences so painful? Again, the causes are legion. One frequent contributor is well illustrated by a story my older brother taught me as a child.

(Continued)

Setting Expectations

Karl Scotland wrote an excellent blog post on Estimates as Sensors. In it, he extols the use of estimates to “sense capability and create feedback for yourself.” This is similar to my point in Estimation as Hypothesis.

At the end of this post, it now says “I don’t recommend using them to make promises and give guarantees to others.” Originally, this said something like “I don’t recommend using them to make promises and setting expectations of others.” I asked him what he did use for setting expectations. He had two responses. “I’d say expectations are set from understanding our capability, refined through sensing, and with a confidence range.” and changing the post to reflect his original intent.

There’s more to this business of setting expectations. (Continued)

Short Overview of Estimation

Back in 2008, Bob Payne and I were working with a team learning to practice Agile Software Development. They were doing quite well at a lot of things, but their sprint velocity bounced up and down like a yo-yo. The sawtooth velocity chart indicated, since they were clearly delivering value at a pretty steady pace, that they were not very good at estimating stories. Bob suggested to me that they might do as well, with less effort, by counting the stories instead of estimating them. (Continued)

What does it mean for an estimate to be right?

What does it mean for an estimate to be right? Does that mean that later actuals had the same numerical value? That the project length, or cost, or end date was the same as the estimate? Is it an indication of the “correct length of the project,” whether or not the project is done in that time? Or is there some better definition of “correct estimate” that we can use? (Continued)

Tracking velocity

It’s very common for organizations to track the velocity of the Agile teams over time. This is quite a reasonable datapoint to plot. Combined with other data, it might give you some insights when you look back, and insights based on data are typically more useful than insights based on opinion. Remember, though, to keep in mind what the data is, and what it is not. (Continued)