Nothing… Apart from pretty much everything with the way we use them…
If you are one of the people who actually enjoy spending their time giving estimates for how long a piece of software will take to write, you might as well stop reading this post. The last thing I ask of you is to leave me a comment below, so we can get to know each other. I’ve never met one of your kind…
If, on the other hand, you are one of the people who has spent long nights working on deadlines, overcommitted on work you couldn’t deliver, or been held accountable for estimates gone wrong for reasons not entirely within your control, (and we’ve all been there) then I would invite you to read on.
First, let’s go back, for a second, to look at WHY we are being asked to provide estimates.
Some of you will immediately think about planning. Some may think that they lead to predictability in software development iterations. Some may suggest we need them in order to make cost-based decisions. Others may argue that the analysis during the estimation process and breaking down into small tasks help better understand the requirements. Some may even go so far as propose that making good estimates shows you’re a good professional (“how well do you know your job, if you can’t provide a good estimate”).
I have heard all of the above arguments. And there is some truth in them all.
Yet, there is an equal amount of bullshit.
Let’s start with Planning
Clients want to know when they can finally get their hands on the feature you are working on. And they want to know that so they can plan other activities, coordinate with marketing, sales, etc. Right?
In fact, this is where the problem starts. Because if we unroll the statement above, we’ll see that you, my dear fellow developer, are now working on a feature that some client expects at a specific date and time.. Obvious? Why so?
My first problem is the “feature” part.
It seems someone has managed to convince the client to buy the outcome of (some weeks or months of) your work. Well, bravó to the sales person cause, in my eyes, what they’ve just done is… sell them a part of the future.
Selling software features is selling the future.
This is a subtle, but important point: they have not sold them your services for this period of time. We are talking about the outcome here, so they have sold them something which does not yet exist.
It may sound strange that I am insisting on this point, because “that’s just how the software industry works”, so you may consider it a given.
However, for me, this is a fundamental concept in our industry that is plain wrong. We have trained our customers to expect features (I’ve always liked how that word resembles “future”), rather than services.
And what is the problem with features, you may ask?
First of all, there’s … the communication gap:
We all know the above cartoon to be an exaggeration of what is happening in software development, but we all also know there’s some truth in it. The feature the client is expecting is different than what the team has built.
Agile Software Development comes to address that problem through iterative development and closer collaboration with the client. And yes, this can help, but only when the client is buying iterations, not features. Not when we are working in fixed scope, fixed budget contracts, with milestones and deadlines.
Estimates == Commitments
So, let’s talk about deadlines. And let’s start all the way up (on the business level), because once we have taken the first step in this direction, it’s very hard to go back.
Since you’ve decided to sell features (in fixed scope contracts), you also have deliverables. Therefore, you have a need for commitments. Because, remember, the client wants to know when the feature you’re working on will be ready.
And that was when they asked you for an estimate. And you gave some story points. BUT by providing one, you have just made a commitment. A commitment to deliver.
This is what we fail to understand about estimates. Estimates are treated as commitments.
They didn’t really ask “how much work is this”. They asked “when is it going to be ready”.
And to put it in our own terms, so that it’s clear:
You probably gave a java.time.Duration, they were looking for a java.time.Instant.
Which brings us back to selling the future. I am asked to make an estimate that is treated as a commitment that something will happen in the future.
And this is how I feel when that happens:
And this is all without touching the “Estimating in hours” pitfall. I am taking for granted that — as an industry — we have moved past that.
Estimates as a planning tool runs the great risk that they estimates are treated as commitments and not as forecasts for the amount of work a certain backlog item includes.