So far, we’ve analysed problems with estimating in four different domains:

  • Fill-The-Bucket: This is the easiest domain to work in. All tasks are similar and uncorrelated. We can extrapolate to figure out how much time the next n units will take to do.
  • Kitchen-Cabinet: In this domain, there is hidden work. We don’t know how much there might be. If we can break down tasks into smaller units, then by the law of averages and the central limit theorem, we can apply some statistics to figure out when we might finish.
  • Journeys: In this domain, work is heterogeneous and interconnected. Different parts depend on each other, and a failure in one part might mean going back to the drawing board entirely. The way to estimate in this domain is to know the landscape and to build in buffers.
  • Fractals: In this domain, Parkinson’s Law is king. There is always more work to be done. The best thing we can do is try and apply ourselves to the highest value work at any given point, and frequently refer back to reality to find out if we’re building the right thing.

Three Dimensions From Fill-The-Bucket

In Risk-First, one of the main messages has been that it’s all about your Internal Model. If you have a good model of the world, then you’re likely to be able to Take Actions in the world that lead you to positions of lower risk.

So the main reason for identifying all these different problem domains for estimation has been to improve that internal model.

Hopefully, you should be able to draw a line through each of these domains and see that there are examples from the world of software development that fit in there. Rather than understanding estimating as a thing which goes wrong frequently, and throw it out as a tool, you might be able to place your problem in this space, and decide which of these axes caused you the issue.

The Time Dimension

Let’s look at change. So far, we’ve considered our problem to be a fixed concern. But what if the problem either changed over time, or as we worked on it?

How does that alter the strategy we use to deal with it? Let’s consider the example of owning a building (maybe a house or a shop), and the functional requirements you have for that building. There are actually only a few basic strategies you can employ for dealing with change:

  1. The Extension. If you need more space for some reason, you can build an extension. But sometimes, extensions ruin the architectural integrity of a building, so you can also…

Lots of extensions

  1. Re-architect. Maybe this involves demolishing some walls, or building a new facade. Re-architecting means taking-away as well as adding new.

  2. **Re-locate. ** If the location of the building is wrong, or the space to build in is insufficent, you’ll end up moving. This might mean breaking ground in a new location, as Apple did par excellence in 2017.

Apple Mothership

In Software

You get the same choices in software, pretty much:

  1. The Extension. Add another software component into your existing architecture, without changing any of the existing stuff. Build feeds into / out of the existing software.
  2. Re-architect. Make changes to the existing software, removing old components and modifying existing ones.
  3. **Re-locate

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” - The Art Of War, Sun Tzu

Where you don’t know the answer, iteration is really the only tool in the box.

  • risk first diagram for iteration

But this comes with a warning: there are plenty of other problem domains that we’ve looked at where you do know the answer.

  • Don’t reach for iteration as a first resort. Make sure you’re applying this technique to a relevant project. Iteration is about scrambling together a few scratch components that may well get replaced in a later iteration. It’s clearly very different from doing the worst parts first that we saw in Journeys.
  • Iterating takes time. It involves Meeting Reality with your users in a large feedback loop. Because large feedback loops are more costly than smaller ones, make sure you definitely need to do this.

Add Your Star On GitHub to receive an invite to the GitHub Risk-First team.

Rob Moffat
Rob Moffat Author of Risk-First Software Development. Developer. Working in the UK.