On Estimation

How we usually understand estimation

Historically we would have a group of product people which would spend their days coming up with new features for the software we are building (how, which techniques they use, etc is not relevant for the scope of this article though). Depending what flavour of development you subscribe to (phase gate approaches, also known as waterfall or agile) the name of the role will vary, but their essential scope of work stays similar: Requirements/Stories are handed down to the team to work on.

“The business” needs to know how long a given work item will take to be shipped. This is not on a whim; we need to know how and when to market these new features and adjust our timelines for these efforts (talking to current customers, creating expectations, etc.).

This is the moment where there will be conversations about “How long will this take? with the technical team members. They will produce some estimate based on their experience working on the product and their current workloads.

And work commences…

… and then, we never on time or budget

There are studies after studies about the failure to deliver software on time or budget. The average cost overrun hovers around 66% and the average schedule overun around 33%.

There are many reasons for this, some technical, but mostly, as Gerald M. Weinberg said, social in nature.

These issues aside, I would argue that estimation is one of the culprits here.

We humans are particulary bad at predicting; specially when it is about the future.

Estimation though, by it’s very nature, is doomed to overrun the predictions. It’s something everyone in the project knows, no one talks about and, when it happens, gets blamed for.

There is nothing wrong with estimating though. It’s perfectly reasonable to say: “I think this piece of new functionality will take us about a week to finish”. It’s a gut feeling, something we cannot really pinpoint, an intuition.

The issue is when we pair that intuiton with an expectation, a certainty.

What could we do instead?

The world of business needs certainty. When there is no certainty, markets fluctuating for example, businesses have a hard time moving forward and grow.

Working on software is an uncertain business (specially when we estimate work) and this is exactly where these two worlds collide.

You want certainty and I can only give you confidence levels.

I want to make clear that I’m not against estimating how long something will take for us to accomplish, what I’m against is how we bake these estimations into the functioning of the business.

Estimation should happen when we are defining the work to be done.

A quick sidebar

Businesses invest capital when they want to grow. This can take many shapes and forms (time, money, etc.), but at it’s core is very simple.

We invest € to get €€ when the investment is realised.

Before investing, the people studying the investment make their risk assesments and estimates. This is done before committing to the investment and assigning the resources towards it.

There is something we can learn from this. When we are defining that work to be done, the technical and buiness leaning team members are in constant communication. This is where questions are asked to clarify what it’s needed and estimates about the completion times are asked.

Once we’ve clarified what this particular investment means, we can commit on doing it, but how?

This is where the business world and the technical world come together. Instead of asking for an estimate for the work that needs to be done (we already did that while we were defining the work) we decide how much time we are prepared to invest on that piece of work.

This practive flips the script and changes the way we, the technical folk, will approach the work.

There are multiple ways of building something, depending on the time (the investment) we have, we will decide to go in one or the other direction. It gives us the ability to make techincal decissions based on the functionality to be build and the time we have to build it. Specifically because we only have the time the business decided to invest in working on this particular work item.

When things don’t turn out the way we wanted to

As we all know, projects don’t always go the way we initially thought they would. As a matter of fact, it’s rare for that to happen.

When we estimate work and don’t finish it in the estimated time, the schedule inevitably gets moved. This creates friction and hits the morale of the team (and not only the technical team).

When our investment didn’t pan out the way we thought (aka. we did not finish the work we planned), we face a different challenge though. It’s a slight change and it’s all due to the language we use.

At this point we have two options:

• Invest more time to get the feature finished (not very different to what we’ve been doing all along).
• Cancel our investment and throw the work away.

Because we are talking about investments and not estimations we change the discourse about the time and effort of the work. We phrase it in terms that help us understand the impact in clearer business terms and act accordingly.

It stops being about overrunning and costs and more about investments that are worthwhile and those which are not.

The addede benefts to this approach are that we not only bring the business and technical people in the team to the table to have mature conversations about the work to be done, but we also start sharing a common language that most of us understand to some extend.

How do you plan your work?