The (Agile) Estimates Overkill
As you saw this headline, many things have popped up in your mind, probably. You might have recalled hours of meetings filled with attempts to come up with a time-to-completion estimate for a project or for a product release. Or, planning poker sessions, which were intended as a spot-on business activity, but in the long run proved to be nothing else but a children’s game, because the actual work took 2x or 3x more time than the estimate attained by playing planning poker was promising.
The sharp question that I want to ask is the following one:
How many times have you felt deep inside that when they make you do an estimate (“them” being managers, or stakeholders, or clients, or anyone else in charge), you end up with nothing else but a waste of time, because later in the project you still face the need to explain why your initial estimate was so different from how things actually turned out, and feel guilty in the process, although probably nothing about the “wrongness” of the estimate was actually your fault?
Don’t get me wrong. My initial intent was pure and well-behaved. I was researching for an article that was supposed to sum up the estimation techniques used in agile, as well as describe their upsides and downsides, and provide a single-point reference for those techniques. However, as I went deeper into the research, I was astounded. It turned out that there are many more articles and write-ups out there in the orthodox agile circles on “How to estimate?” as opposed to “Why estimate at all?”
In those few cases, where I saw some attempts at explaining “why?”, they stroke me as incongruent and built on a loose logic. This very fact of the looseness of “why?” puts a big question mark on the validity of the “hows”, because the “how” is a product of “why?” or “what?” I cited those words in one of my previous posts, and I’ll repeat them one more time, because this axiom is universal, and works for all things life and project management alike:
The hows will appear if the what becomes clear.
Let’s take the scalpel of pragmatism and dissect the faulty logic behind all things agile estimates.
What is an estimate?
Is it a measure of commitment? Or is it a lazy talk? I tried to find some stats on the actual usefulness of the estimates in story points, and how they’ve proven themselves valid in the bottomline world of business. I found none. From my own experience, I know that estimates never work. I’ve seen this in project-by-project software development and in product development.
It’s impossible to estimate something that is being built for the first time.We never build the same feature twice. — source
One viable example of a valid use of estimates that comes to my mind goes as far back as to the early 2000’s, when people wanted simple e-commerce web-sites developed, or dating sites, or something of that kind. Having built a handful of such web-sites, software contractors were more likely to give their clients a realistic estimate of completion, because these web-sites didn’t come with a heavy baggage of residual debris, such as technical debt, bulky databases, or an octopus-like architecture, which just spreads, rendering futile any attempts to commit to the bottomline “get the sh..t done on time” stuff.
Next, if any attempts at estimating are futile, then why do most companies continue to play “the estimating game”, which resembles courting in its vagueness, but unlike courting promises no pleasure ahead, only the ever increasing snowball of mess, feeling guilty, unproductive, and unaligned with the only goal that matters: get the job done well and on time?
Sometimes the fool who rushes in gets the job done. — Al Bernstein
Stay tuned for the answers and even sharper disclosures.
Related:
Becoming a Leader-5: How “Why” Overrides “How To”
What’s Wrong With Your Questions
