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.


Sliding Doors – A Tale of Two Agile Teams

Movie poster for Sliding Doors

In the 1998 movie, Sliding Doors, Gwytheth Paltrow experiences two very different storylines in parallel because of one small difference. In one version, she leaves work early, catches the tube and arrives home to find her boyfriend in bed with another women; in the alternative version, she is slightly delayed, just misses the tube, and doesn’t catch him. The movie plays both versions side by side, switching scene by scene between them.

This blog is based on a real life project, where we were asked to help automate some manual business processes. As we began exploring the problem space, it turned out that another team had also been asked to do the same, but were taking a different approach from us. While we were thinking about business and user goals, they had decomposed the problem functionally.

This story describes how these two approaches differ, particularly with the outcome, tries to explain why goal decomposition is better, yet despite this, is still relatively rare to see.

Continue reading “Sliding Doors – A Tale of Two Agile Teams”

Story Mapping – Getting the best of both worlds!

Jeff Patten’s User Story Mapping is great technique that many teams use early in the development of a solution. His book describes the process in detail, and I highly recommend it. There is also a simplified explanation in the ‘Modelling Stories and Scenarios‘ chapter of Agile and Business Analysis.

User Story Mapping solves some of the problems that Agile teams face when trying to balance the desire of the stakeholders to know details about the whole project against the needs of the Agile team to focus on the short term, high certainty requirements, and avoid big-up-front design.

The approach allows the team to expose the whole project scope in a way that is quick to do, produces enough detail (but not too much) and allows the work to be prioritised.

Stakeholders can indulge themselves in the art of the possible, exposing a breadth of capability for the solution that may far exceed the resources of the team to deliver. This is only OK if it doesn’t consume a lot of effort, or set unrealistic expectations, so it is important to manage that aspect. However, by being able to see the whole solution, stakeholders are better able to prioritise shorter term goals, and direct the team’s focus on what they want first.

Coupling User Story Mapping with a strong focus on Goals and Goal Decomposition allows teams to focus on the right things. Since User Story Mapping can allow teams to functionally decompose the problem, it is really important to ensure that the slices of user value relate to goals rather than functions. For an example the difference this can make in practise, read about A Tale of Two Agile Teams.