Tag: estimation

Posted on by — 2 Comments

Billy Pilgrim and the software estimation debate

Warnings:

  • tl;dr
  • sarcasm
  • calories from fat: (don’t ask)

I’d like to begin with an insightful quote. Until I find one, here’s a quote from Vonnegut:

“I am a Tralfamadorian, seeing all time as you might see a stretch of the Rocky Mountains. All time is all time. It does not change. It does not lend itself to warnings or explanations. It simply is.”
— Billy Pilgrim in Slaughterhouse Five, Chapter 4 (Kurt Vonnegut)

The online debate about software estimation may well be the greatest waste of pixels since the invention of porn. Like porn, the debate comprises a never-ending repetition of the same scene over and over again, the very definition of “boring.” And the actors conclude each day in the same state they were in when they awoke. Every day the same, every day exhausting, every day pointless.

The argument, like Kenny of Southpark, refuses to die. It wakes up each morning as if nothing has happened. In a sense, I guess, nothing has.

Anyway, here’s the thing: Despite people’s best efforts and their protestations to the contrary, no one can predict the future accurately and precisely.

Continue reading Billy Pilgrim and the software estimation debate

Posted on by

Short-term planning: A continuum of effective practice

There’s been an ongoing discussion in IT circles about estimation. The discussion dates back as far as I can remember in my career. As far as I know, it began much earlier than that; possibly around the time people began to apply software to serious matters, which would have been a few minutes after the first digital computer was powered up.

People have focused on estimation for such a long time that I sometimes wonder if they have lost sight of the purpose of software. The practical value of software is not realized through an estimate. An estimate is not a product. Customers don’t buy estimates. Even when a client pays a consultant to provide an estimate for a project, the estimate itself is not the thing that ultimately interests the client. It is only a step toward making a decision about whether and how to go about a proposed initiative. An estimate is a means to an end, not an end in itself. Continue reading Short-term planning: A continuum of effective practice

Posted on by

An old metric revisited: Comparing estimates with actuals

Back in the Old Days, project managers seemed to be obsessed with comparing time-based task estimates with the actual completion times of those tasks. When estimated and actual times didn’t align, we were advised to get better at estimating. The goal wasn’t really to learn to create perfect estimates. The goal was to achieve some level of predictability in an inherently unpredictable process for purposes of short-term planning.

Nowadays we know that the fine-grained estimates we might use to inform our short-term planning in the course of a project are not “the product” for which our customer is paying, and therefore are a form of “waste.” We’ve looked for (and found) alternatives to time-based estimation that can provide the information we need to plan our work without the overhead of preparing time-based estimates for individual tasks.

At two different clients this year, I’ve seen people comparing “estimates” (actually, relative story sizes) with the actual completion times of user stories, but not for the purpose of short-term planning. Continue reading An old metric revisited: Comparing estimates with actuals

Posted on by — 4 Comments

The future casts its shadow across the past

I don’t know the origin of that saying. When I first heard it, it was presented as ancient Chinese wisdom. In the West we often attribute pearls of wisdom to some named or unnamed ancient Chinese philosopher. I suspect many of the attributions are not historically accurate. In any case, the saying suggests — correctly, I think — that by examining the past we can make some predictions about the future…within limits, of course.

One of the hot topics of discussion in software development circles these days is the question of how we can make useful predictions about the future for purposes of planning software delivery activities. The subject turns out to be trickier than I had, um, predicted.

Continue reading The future casts its shadow across the past