The horizon of software development estimation by Simon van Dyk

Anything is possible if you believe

Howard Stark says “Everything is achievable through technology” and I fully agree with that sentiment. I often say, “You can build anything with software, so it has become even more important what you decide to build”. When I have my product owner hat on, I often find myself worrying if what we’re building is actually going to be valuable to our users, or if it’s just an extremely costly experiment we’re running for our client.

The kicker is that you don’t truly know what is valuable to a user until they actually use the software. So estimating software that is actually useful can be a challenge, especially if the goal is surrounded by uncertainty. To add to that, we are simultaneously figuring out what we need to build and how, while we build it.

How far into the future should I be estimating?

On the one hand, if you estimate as you build the software, you spend the least amount of time predicting the future, because you have the most amount of information available to you at the time.

The downside to this approach is that you can’t confidently answer the questions “How long will it take?” or “Are we on track to hit our development milestones?” - and so, there is no visibility of the road ahead.

Then on the other hand, if you estimate the entire project today (waterfall), you spend most of your time predicting further and further into the future with the least amount of information available to you - this results in so many assumptions, biases and general unknowns that influence your estimation.

You: That’s not an answer, Simon. Me: You should try estimate enough work to reach the horizon of your software project.

What is the horizon of software development estimation?

Once I came to the realisation that estimating beyond a certain point results in diminishing returns, I quickly began to wonder how far ahead I should be planning.

The horizon is that period of time in the future that enables us to accurately estimate how long a software feature will take to build and then get into the user’s hands.

The horizon can be seen as that point just far enough into the future that fosters sufficiently accurate estimations, which in turn can be used to predict a completion date. If you have obvious unknowns then you have overshot your horizon.

I found this metaphor to be quite useful when discussing how far ahead we should plan and in what detail. The simple answer for me is, as far into the future as is useful.

Imagine yourself standing on a beach looking out at the horizon. Beyond that point, you can only guess what is lurking in those waters, but you have visibility from where you stand, to the horizon and can make informed decisions from that visibility. If you replace distance with time in this metaphor, you can can use it to discuss how far into the future your team can estimate.

Find the horizon of your project, and try stick to it when planning. Focus more on addressing the risks (unknowns), technical or otherwise, and your estimations will soon become more accurate and more relevant.

Ok, how do I do this?

When I was estimating too far into the future, I noticed that my estimations became stale and the features I estimated on were often de-prioritised, resulting in them not getting developed. I spent a lot of time estimating work too far into the future, but it was not time wasted. There was a learning curve and I realised I needed to bring back my horizon slightly.

When I was estimating not far enough into the future, you will have no daily or weekly development goals and cannot answer the question “what do you need to complete this week or this sprint”. I found myself constantly stopping what I was doing to check with the product owner or designer the features specs because I hadn’t resolved enough unknowns to confidently complete my tasks. In this instance, I wasting time during implementation that can be avoided by pushing the horizon out slightly and doing more estimation and planning.

I’ve found the distance of the horizon to be dynamic, and so you need to use some common sense and adjust it as is necessary. Typically it’s very short for a startup, and a bit longer for a rebuild of an existing product.

My project’s horizon is currently at around 10 days.

What is the horizon of your software project? 2 weeks? 3 days?

Questions? I’d be humbled and happy to help.