We are terrible at quantifying and understanding risk. More often than not, we err on the side of positive outcomes, especially if we think something is pretty likely to happen. You can explore this deeply in the classic Thinking, Fast and Slow, but today we’ll look at risk vs optimism in software development planning.

If something is complex, novel or collaborative, then it’s really hard to plan, with software, it’s all three! Previously we’ve looked at the reasons why we use agile methods, and why launching early is important to the creative endeavour, and why “When” is a bad question. Now we’ll bring some number to the party. Exciting!

Sometimes we need to hit a particular date or milestone, usually when there’s an external requirement (think a new law coming in to force, or an immovable date like Christmas). How can we understand the risk we are facing, and also report them out accurately?

Optimism is not our friend in these circumstances. There are a number of ways to be optimistic when planning against these fixed dates, here are the top three:

  1. This is an easy problem to solve
  2. We’ll get faster as we go
  3. Nothing unexpected will happen

A new or na├»ve planner will come up against all of these, but might not recognise them. They will look at the requirements, split them up, estimate them and slot them into your preferred timeboxes. Almost certainly this means your plan will slip and you’ll miss your target.

Imagine that you hit sprint commitments 90% of the time. That’s pretty good! However, that means within five sprints, you have more than 40% chance of missing a commitment. As soon as you miss one, you are playing catch-up, and experience shows us that never actually happens.

Being right 90% of the time is also massively unlikely, but it’s a nice round number that’s pretty comforting in planning world. If you only really are spot on 75% of the time, then after 5 sprints you’ll have missed at least once move than 76% of the time!

To beat this optimism, put some evidence into your thinking. Track two things. First off, how hard you thought something would be at the start. Second, the end-to-end time to complete it (which includes everything to get it really and truly done and out into the world).

Generally, we’ll perform about as well as we did last time. Maybe a little better, possibly a bit worse, but tracking these two numbers mean you’ll be able to get good confidence in how often you hit those commitments.

Next up, grab some contingency. If you have a fixed date, then aiming at that time is the high risk approach. Remember, you are super likely to slip up, even if you are right 90% of the time.

Assuming that 90% figure, if you extend that five sprint timeline to six, then the chance that you miss commitments twice is only 18%. That’s over 80% confidence of success, much better than your 60% working to 5 sprints exactly.

These calculations can be performed with the help of a binomial distribution. It’s all pretty theoretical, but it can help to shed some light on unexpected outcomes.

Finally, do the things that are most important first. That’s a key part of success in the agile world, and it still helps even with the fixed commitment.

It’s not always the hardest things, but the ones that matter most. If there’s a feature you simply must have or else risk breaking the law, then do that first. If it’s nice to have, or a general solution to the problem, or something else that’s not vital, put it to the back of the queue.

This means that even if you do end up missing more than expected, at least you’ve done the biggest bits first. When a deadline is looming and you’ve got the ‘Musts’ done, then the ‘Maybe’ quite often just falls by the wayside.

These techniques help you overcome optimism, plan better, be more agile and keep more of the commitments you make.

Measure the difference between your estimates and the actual time taken, grab contingency and do the important things first!



The value of planning is the process, it’s very rarely the plan itself.

An effective planning process drives out the complexity of what you are trying to achieve. It shows you the priority, who needs to get involved and where the difficulties may be. You also get to say what you aren’t going to do, which is especially valuable before you’ve invested a lot of effort.

One quick test for effectiveness, check the level of detail you are working to, and measure it against the scope and duration of the plan. If the scope is more than a couple of weeks, then anything talking about specific days or people is too much detail to be useful. By the time you are looking at a year, then the plan is more of a strategy, and you are better placed to think about a focus of effort and the outcomes you are chasing, rather than the specific things and order they will be done.

Once you’ve built a plan, get ready to rip it up. Things change, and the only thing that’s uncertain is how quickly they will change. If you stick dogmatically to the plan, you’ll quickly find yourself chasing dates that don’t make sense, or pushing for features that are no longer needed.

The most painful failed projects are those that treat the initial plan as a rigid structure, rather than a guide towards a potential future.

Still, keep cycling through the planning process. Take in what you’ve learnt, what’s been completed and consider what’s changed. This means you are not starting from scratch each time, but course correcting with more information.

Iterating is key, especially in a fast moving environment. If you find planning a chore, then doing it little and often should cure this feeling. If you plan by six-month cycles, try cutting it to three and I’m sure you’ll get a better outcome.

Create your plan, throw it away when it’s no longer helping!