Predicting the Future – Can Up Front Estimation work?

In an ideal world, agile teams don’t need to estimate at a whole project level. They get given an overall project goal, and work together with their customer to work out how to achieve it. In time, they may settle into a more predictable velocity that allows them to predict with some accuracy what they can achieve in an average iteration, but that isn’t going to happen right at the start.

However, that’s not how the world works. In reality, the customer often want to know things in advance. Typically:

  • How long will it take;
  • How much will it cost; and
  • What will I get at the end?

This is the classic project management ‘Iron Triangle’, and traditional projects are set up to provide answers to these three questions at the beginning. They will then pretend that the process they are following will guarantee that they will still be true at the end.

The three lies of project management - Cost, Scope and Schedule

One of my favourite quotes from Scott Ambler is that every time someone asks you to tell estimate the whole project, they are really asking you to lie to them; you just aren’t sure which of your estimates will be the lie (clue: it’s probably all of them).

But despite evidence overwhelmingly showing this to be true, particularly with IT or change projects, the practise still persists. For some eye opening statistics, see this Wrike blog which is promoting using project management approaches, yet still shows that less than a third of those using formal methods stay on schedule, less than 2 out of 5 stay on budget, and barely two thirds deliver the expected scope!

So, how can we get around this paradox? – as an analyst, you don’t want to lie to your customer; but the customer expects at least some idea of the cost to get what they need.

The secret lies in two areas:

  • Do ‘Just enough‘ analysis, ‘Just in time‘;
  • Rely on the fundamentals of agile estimation: Wideband Delphi and Relative Sizing.

The first thing is to properly understand why your customer is asking you to estimate the project. Without this knowledge, it is impossible to know how much detail you will need to go into, nor when you can stop. It is also an opportunity for you to challenge your customer on what she needs the estimates for; and whether she needs them at all.

Many people, particularly those unused to agile delivery, assume that fixed price delivery is preferable to time and materials. Therefore, they need to know in advance, what the deliverables will be, and what the supplier is being asked to price.

However, as Craig  Larman and Bass Vodde explain in their ‘Practices for Scaling Lean and Agile‘ book (and in the sample chapter at, this is not true. Mature, successful agile outsourcing use time and materials contracts, along with strong collaboration and trust. This feels counter intuitive but isn’t.

Agile projects expect change, especially to the scope. Agile works precisely because the customer uses the early delivery of working solutions to better understand their problem, and adapt the solutions accordingly. Therefore, it would be impossible to accurately predict the outcome at the start, so it is illogical to even try. However, we are certain that the solution will require people to work on it, and may require the purchase of some materials.

As long as the customer is properly engaged, and the team is making tangible progress towards her goal, then time and materials is an ideal way to describe the contract. All that is required in advance is confidence that the budget available will deliver enough value. Since the customer is in control of when to stop, and what to prioritise in each iteration, they are already in control of their scope, their cost, and their schedule.

Nevertheless, this isn’t always possible. Sometimes it is necessary to agree some level of scope or commitment up front, and this will require some analysis. There are several things that can contribute to this analysis, and draw on the principles of agile estimation – involving many people (Wideband Delphi); and comparisons between things (relative sizing). Some examples are:

  • An understanding of the problem, perhaps by some ‘Just enough’ modelling, or workshops like Story Mapping;
  • An understanding of your team’s capability, perhaps with historic analysis of velocity or deliverables;
  • An understanding of some previous project that can be compared to the current project;
  • A measure of the size, perhaps by creating business epics, a high level business architecture, or a Use-Case model;
  • Creation of prototypes, perhaps extremely low fidelity such as cardboard mock ups of products, or hand-drawn wireframes of screens.

It is important to ensure that as little effort is put into this analysis as possible – just enough to be able to answer the customer’s questions about the overall project. The sooner the team is engaged in actual early delivery, the better.

To do this, keep the size of the things being analysed or modelled as large as possible. You know they will be broken down later, so keeping them big means you are doing less nugatory work if they are eventually reprioritised.

It is also important is to remember what assumptions you are putting into your analysis. As the team starts iterating, they will learn more about the project, and will be proving or disproving those assertions. When this happens, it is an opportunity to revisit your high level analysis and refine it with your new knowledge of the assumptions. This is particularly important if the customer is relying on your early estimates for higher level reporting.

Estimates made before the team starts will always be poor quality, unless the problem being solved is trivially simple. They can help justify investment, determine the initial size and shape of the team, inform future workforce development or hiring decisions and predict when the customer may have a version she can start using. However, they should not be used to create project milestones far into the future or become hard dependencies on other projects.

To conclude, it’s best to avoid up-front project estimation if you can. Understanding why your customer thinks they need detailed estimates will help you get the amount of analysis correct, and may provide an opportunity to persuade your customer that she doesn’t need them after all. If she does, keep things high level; business level epics or outcomes, high level goals and ranges (i.e. 6-9 months) are good.