Or is it?
It’s not so much the act of estimation that’s the issue. We accept that estimation can be a useful tool to help teams gain a shared understanding of a work item, and to break work down. It’s what we do with those estimates afterwards that matters. Other than the value to the team, the most common reason for doing any estimation is in an attempt to be predictable: we want to be predictable so that we can budget for projects, and provide our stakeholders with some understanding of the progress of those projects.
Basically, our stakeholders want to know what they are buying, and that we are actually doing what they are paying us for.
What’s the problem?
We know the least about any potential solution at the beginning of a project. There may be several options, some of which may need us to start work before we can discount them. Software development is not deterministic. Our stakeholders also change their minds. What they ask for at the beginning of a project will inevitably change as the project progresses. It may be that market conditions change, which, in turn, means that what was defined at the beginning of the project no longer satisfies our customer’s needs.
In order for our estimates to come close to how long something might actually take, we need to know everything about what we are estimating. Can we really expect people to estimate something they know little about and that they’ve never done before?
To provide this would mean doing in-depth analysis and writing specifications for the entire scope at the start of the project. Didn’t we say that scope will change?
What is the alternative?
We are trying to solve a problem using estimates, which estimates can’t solve: we want to know at the start of the project how much it will cost so that we can budget. We do this by estimating how long it will take, and extrapolating cost from there. However, things will change, and that will change the cost. We blame our teams for not providing accurate ‘estimates’, forgetting that they were never going to be, while glossing over the real issue of defining the cost of a project.
Let’s lay out the key points;
- The Number One, most important thing to recognise is that we estimate because we want to be predictable, but estimates don’t give us predictability
- We will never truly know how long something will take until we’ve done it
- Lack of visibility on project progress leads to a focus on estimates. “when will it be done?”
Armed with this understanding we are forced to challenge the way in which we have traditionally delivered projects.
We can work closely with our stakeholders throughout the project.
They can help us with the decision to take one path over another, to prioritise one feature over another, and we can get their feedback as early as possible, knowing that they will change their mind. Collaboration provides visibility and builds social capital.
We can get software live as soon as possible.
Not only does this deliver value throughout the project, removing the need to focus on the end date that our estimates are meant to provide, but it means we can start to collect feedback from our customers, which can also drive the direction of a project. Rather than relying on estimates to provide predictability, let’s use regular delivery of working software to do that instead. Predictability builds confidence, which in turn builds trust.
We can break down requirements as late as possible.
Doing any more than that is a waste, as they will inevitably change. Keep requirements at a high level until it’s time to use them, and ensure that projects are as small as we can make them.
We can accept that it’s impractical to define the cost of a project before we’ve started it (and improbable that we would get it right), and find a different model for budgeting.
An alternative does exist, and so do the principles that support that way of working.
We can stop making decisions based on time (or guesswork), and start assessing projects on the value they deliver.
If undertaking a project will truly provide value (or there is an opportunity cost to not undertaking it), and we can ensure the project delivers value early and often, will we decide not to undertake it just because we don’t know how long it will take?