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
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
This model isn’t based on release planning at Guinness. It’s based on drinking Guinness.
It’s the end of a work day. You and your mates are going out for a drink. Initially, you’re thinking you’d like to have three pints of Guinness. How do you place your order?
If you’re a traditionally-minded software development project manager, you’ll order all three pints at once, in the same glass. When the bartender tells you three pints of Guinness won’t fit in a one-pint glass, you’ll pound your fist on the bar and shout until he finds a way to make them fit. After all, the reason he doesn’t want to pour three pints into the glass is that he’s either lazy or incompetent, or both. Once you let him know who’s boss in no uncertain terms, he’ll get those three pints into the glass, one way or another.