Alternatives to Software Estimation: First, know what problem you are trying to solve.

One problem with software estimation; it is deployed by default, an assumed part of the development process. A way to challenge such defaults is to get specific on what problem we are trying to solve.

Photo by Nighthawk Shoots on Unsplash

This post is a continuation of the topic introduced here:

Estimation does not help us learn how well our software will meet its aims; putting software into use does.

The issue with the software practices ‘we’ve always done’ is they remain unchallenged. They become detached from the reasons we began doing them in the first place. The context around us changes, and the relevance of continuing these practices goes unchallenged, particularly if the practice is associated with multiple benefits, such as software estimation. A similar related example is roadmaps.

To avoid becoming an organisation weighed down by its collected calluses, examine what is there and regularly challenge whether it provides enough value to continue being there. That doesn’t mean thoughtless cutting—that’s irresponsible. It requires identifying individual needs and then assessing what would be the most effective response to that need. Break apart related needs that may have become clustered in people’s minds.

For instance, with estimation, there is a range of ideas around effort, time, people, available resources and other coordination and logistics considerations that are all part of the same big question.

But it is not the same question. What executives might need to know about timing may be adequate to the nearest quarter and may be low stakes as to whether that is accurate. Planning when to work together may need far more granular accuracy for coordinating among collaborators. Other questions may be about risk to the organisation, such as what likely release timing may mean for customers or the competitive situation in the market.

One great example of expectation management in a sales context can be the presence of a roadmap as a response to queries or objections about missing features or capabilities. Such an information asset, however, is far more reliant on the prioritisation approach than on software estimation.

Some leaders claim they want to know what something will cost before considering the priority. The problem with this thinking is that the cost is a function of uncertainty, and estimation does not tackle the most significant sources of uncertainty—what you don’t know. Working on a problem is the best way to demystify what is involved and reduce uncertainty.

In other words, what if we are delaying something because, whilst it's important due to what we don’t know, we think it's much more effort than it is? And our response to this has been to instead work on things we think are less effort but know are less important or potentially less impactful. What is the effect of a company that does this over and over again versus one that prioritises its most important problems and breaks down its riskiest assumptions to find the shortest path to the most value?

Other ways to address what estimation is used for

Once we know the problem we are trying to solve, we can identify the most effective practice for that need and hire that instead. Often, this option helps us progress on the work and thus introduces information we don’t already have, bringing us to new learning opportunities.

Prioritise riskiest assumptions first - Reducing uncertainty by starting development

In many cases, uncertainty may be identified in software estimation and could occupy discussion and debate. It may be better to tackle the uncertainty head-on to resolve it by doing.

When we keep too many requirements defined but unimplemented, they become a form of inventory, with a cost and decay associated with their lack of implementation. There’s also an opportunity cost to holding uncertainties undiscovered. Every time uncertainty is maintained, and the work sitting behind that uncertainty is not progressed in favour of something more certain, we realise that cost.

If these uncertainties are associated with our potentially biggest impact improvements, then the opportunity cost of not reducing the uncertainty could be quite high. Given its uncertainty, it may be low for any given instance. Still, across a range of uncertainties, the probability is a proportion of those uncertain opportunities will have a significant pay-off.

Always estimating and then choosing based on estimated cost could create a set of potentially lucrative opportunities that will never be attempted, as the uncertainty translates to estimates of high effort, which lowers the likelihood of that opportunity being attempted.

Working smaller - vertical value slicing

Some in the attempt to make a case for estimation have described vertically slicing work, i.e. dividing a larger valuable increment of software into separate valuable elements, as a form of estimation. There are some potentially common aspects, but there’s no attempt to reconcile the effort to time, only if it might be achievable in the next time window.

Outcome roadmaps

When stakeholders ask for a roadmap, the assumption is often a list of deliverables and dates, as that is what has been seen elsewhere. But if we examine what they need this information for, we will often see that a lot of the detail that has been requested is not actively used. For instance, these other parts of the business might not plan their activities as far into the future as a typical roadmap. In this traditional form of roadmap, we may be making estimates that, for significant parts of the roadmap, won’t be used by the collaborators elsewhere in the business. That can be a significant effort for no value.

They may need the sequence of opportunities being tackled or a notice period leading up to a release. These needs may be better served by a different sort of roadmap.

There is an approach to roadmaps that focuses on prioritising outcomes rather than specific deliverables. One or more options may be tried to achieve the prioritised outcome. This roadmap style organises priorities with different degrees of specificity, usually in categories of Now (often the immediate time window of 3-6 months), Next (6-12 months following), and Later (beyond that). Opportunities in the Now will have more details defined and agreed upon, Next some details but less, and Later tends to be no more than a list of opportunities.

Event Modelling

I was chatting recently with Arjan Noordhoek, who suggested that Event Modelling might be a good alternative to making progress compared to software estimation. This could be a whole post, so I will return to it again in a future post, or maybe ask Arjan to contribute to a guest post.

Fixed time, variable scope

Many agile practices suggest working with a fixed time and variable scope instead. This approach presumes that if we prioritise the most important aspects of the software first and deliver to an always releasable level of quality, then whatever we have by the chosen date is what we will release.

There are no doubt scenarios where this approach isn’t viable. Still, conversely, there are many scenarios where it is viable but not practised, with a lot of low-value software being delivered because of the size of the guesses on what will be valuable for the user.

Outcomes-based development by long-lived teams

Outcomes-based software development is a flow-based delivery focused on constantly measuring whether the software has the desired effects on users, customers, and the business.

Are the users using what is delivered? Are the customers seeing the value and buying or staying customers? Is this contributing to a viable business model?

This model tends to fit long-lived teams because of the time invested in learning the user, customer, and business needs and measuring and validating the software, which has the desired effects and continues to have the desired effects as needs and market forces evolve.

Software Estimation is not the same as Software Forecasting.

Suppose software estimation aims to determine when a milestone might be achieved for coordination. In that case, software estimation is one way to try and determine this, but it is a fairly static method. The results decay and remain brittle, and it is increasingly likely that they will prove inaccurate, and plans will need to change anyway.

Software forecasting is an approach to measuring the average time it takes to deliver increments. It has various methods associated with it.

The approach associated with a few agile practices of using planning poker and story points to produce burndown charts or a velocity calculation is one approach; in my experience, this can work in a narrow range of cases where the nature of the work is quite predictable already—such as producing mostly web content with little novel technical innovation required. In these cases, it's superior to software estimation. Outside, this fairly flawed approach is best avoided for the same reasons as software estimation. More on the limitations here:

https://observablehq.com/@troymagennis/story-point-velocity-or-throughput-forecasting-does-it-mat?collection=@troymagennis/agile-software-development

There are a variety of lean forecasting approaches you can read about, such as:

https://repositorio-aberto.up.pt/bitstream/10216/128576/2/412448.pdf

How little do we need to do vs how little can all this cost?

Another driver for the call for estimation is the assumption that the cost should be minimised for any given investment. Minimising cost is ideal if it doesn’t limit the potential of the investment. Unfortunately, that’s precisely what minimising costs can lead to. In a scenario where you are working towards an outcome and tracking progress by meaningful indicators of progress towards the outcome, there will be natural constraints on overinvestment.

A better question is:
‘How much are we willing to spend to achieve this outcome?’

Using this as a constraint on the upper bound of the investment indicates when an investment may become unprofitable.

This approach reduces the push to estimate so choices can be made that minimise cost. This helps avoid unnecessarily excluding options that may give you a better chance of achieving the desired outcomes because you are less certain that they minimise the cost.

What scenarios might software estimation be used for in your organisation that might be addressed by other approaches? Do you use any of these approaches or other approaches in the place of software estimation? How is this working for you? Share your experiences in the comments.

---

Take advantage of our next livestream, episode 4 of CTO Life Line - the livestream conversation devoted to supporting CTOs.

This episode's topic is 'Are organisations fit for humans?' Special guest Matthew Skelton, co-author of Team Topologies and CEO and founder of Conflux, will help us tackle this topic.

https://www.linkedin.com/events/ctolifeline-4-areorganisationsf7206062903483920