Marcin Niebudek wrote an article, in which he adds a budget line to an agile burn chart, measuring both in percentages.  Nice to see I’m not the only one doing that. (Even if he does draw the chart up the “wrong” way ;-)

I’m looking forward to being part of an interesting conference, and hopefully helping to lift the profile of EVM in New Zealand.

Link to presentation abstract

( The abstract’s reference to “Number 8 wire” may be unclear to overseas readers :-)  The phrase simply means “New Zealand ingenuity”, in this part of the world.)

This is particularly important when describing it to people outside EVM’s traditional strongholds of defense and aerospace.  Outside those areas, EVM is under-utilised, and I suspect much of the reason is due to its apparent complexity.  I’ve been an EVM fan for about 5 years now, and I still come across unfamiliar acronyms.  If EVM is to be more widely used, it has to be presented in a way that is accessible to a wide audience.

Here’s what I came up with:

EVM, Distilled to a Pair of Simple Rules

Expanding on Rule 1

We compare actual cost with actual progress because that is the only comparison which bears any relationship to the final actual cost of the project(*). In projects run without EVM, it is common to compare actual cost with planned cost instead.  That simply tells you whether you are spending money as fast as you planned – a fairly useless thing to know if don’t know how much progress you’ve achieved for your money.   Another flawed alternative is to compare actual progress to planned progress.  That can be misleading – you may be making enough progress, but overspending (e.g. on overtime) to keep up with the schedule.

We make the comparison numerically because that’s the best way to get an objective comparison, minimising the subjective bias that tends to creep into our personal assessments of project status.  Making a numerical comparison necessitates one of EVMs most distinctive features: cost and progress must be measured in the same units.  Traditional EVM solves this by measuring progress in dollars, which is counter-intuitive for the uninitiated.  In the ‘lite’ EVM approach which I advocate on this site, cost and progress are both measured as percentages so they can be compared easily.

Expanding on Rule 2

Rule 2 necessitates another of EVM’s distinctive features: to predict the future from the past, we must measure the size of past and future tasks in the same way.  Because estimated size is our only measure of size for future tasks, we must also use it as our measure of size for completed tasks.  I.e. our progress to date is calculated as the sum of the estimated sizes of all completed tasks (not their actual sizes).

But the biggest challenge with rule 2 is psychological,  not technical.  When a project is going badly, we want to believe that the future will be better than the past.  We instinctively convince ourselves that we can catch up.  Sometimes that’s true (as long as our corrective action is appropriate), but sometimes it’s not. The great thing about EVM is that it provides an objective measure, independent of our tendency to kid ourselves. That objectivity can feel uncomfortable at times — particularly on those occasions when we actually are kidding ourselves :-)

But look at it this way: the impartial prediction provided by EVM is actually a good thing.  How many times have you been on a project where you knew it was doomed, but those around you (or more likely, above you ;-) kept insisting it was going to be OK?   With their heads buried in the sand, the project probably got even worse(**).  But what would have happened if they had used EVM instead, and if they had followed rule #2? They may well have responded to the problem with something more productive than denial.

EVM actually helps you respond to problems in a productive way.  It gives you the bad news relatively early (e.g. approx 20% into the project).  If you get the bad news that early, you can usually do something about it.  After you’ve done so, EVM can show  how well your corrective action is, or isn’t, working.

My point with rule 2 is that  it’s not enough to simply wish, hope or believe that the future will go more smoothly than the past. For example, it’s not enough to hope future tasks will be completed at their estimated costs, if EVM shows consistent overrun in the past.  That’s just kidding yourself.  Instead, you have have to actually take meaningful corrective action.

If you’re serious about project management, you must be serious about obtaining an accurate and impartial assessment of project status.  Earned Value is the best way to get it.

Feedback Please

Do you find these two rules useful?   How could I explain them better?

If you are not currently using EVM, do these rules help to explain what all the fuss is about?

If you are using traditional EVM, do you feel these rules fairly represent the “heart” of what you are doing?  Or are they off-target, or merely stating the obvious?

Footnotes

(*) An exception would be if you really can cancel-after-any-phase.  In that case, you know what your final cost will be – it will be your pre-arranged project cost. (You just don’t know the final scope, unless you predict it with EVM.)  Another exception would be if you have linear planned progress and guaranteed constant team size. In that case, cost is directly proportional to elapsed time, so you can use your linear planned progress as a proxy for actual cost.  I believe that many Agile processes implicitly assume that at least one of these exceptions applies. It would be better to make the assumption explicit, to more readily detect cases when it doesn’t apply.

(**) To be clear, no, this paragraph is not a reference to any of my current colleagues or bosses. The now-historical situations that inspired it shall remain nameless ;-)

I’d like to suggest an answer.  Let’s illustrate it with an example.  Consider an agile project that’s been estimated at 375 points in size. (To my non-agile readers, “points” are just a relative measure of task/feature size.  So for instance, a 20 point feature is estimated to require twice as much work as a 10 point one.  In this project, all the features add up to 375  points).

Also, imagine that our sample project is scheduled to take 12 weeks and we are now half way through the project. After 6 weeks, the team has completed 132 points’ worth of work.   The team leader reports that they are a little behind, since by this time they should have finished 187 points (half of 375).  After speaking with  everyone on the team, he is confident that they can make up the lost ground.

Question: how much faster will they have to work, if they are to finish the project on time? Will they have to work 10% faster than they have so far?  20% faster? 30% faster?

Get your own gut-feel for the answer, then scroll down.

The answer is eighty four percent.  To deliver on time, the team has to produce 84% more output, per week, than they did in the past.  That’s almost double.

Most teams, I suspect, don’t realise just how much faster they need to go.  We look at the status, and think,”Well, we’re a little behind, but it’s not too bad.”  We might even crunch some numbers.  In this example above, the team should have completed 50% of the work, but they have only done 35%.  You look at the figures, see 50 and 35, do the subtraction, and end up with 15%.  That doesn’t seem to bad.  15% is not very much, and seems well within our abilities to compensate for – perhaps with a little extra work, and good intentions to “work smarter”.

But we’re fooling ourselves.  We are forgetting two things:

1. The gap is not 15% of the project, it is 15 percentage points out of the 50 percentage points we are supposed to have by now.  15 / 50 is actually a 30% deficit.  So we are further behind than we think.
2. Not only are we further behind than we think, but catching up is harder than we expect.  We look at the remainder of the project and think, “We just have to go a little faster than we planned”.  That’s true enough, but we forget that “faster than planned” really equals “much, much faster than we have actually been going”.  After all, we do not have to achieve an improvement relative to the plan, we have to achieve an improvement relative to reality!

It is these two factors which mean that it requires an 84% speedup to compensate for a “15%” gap.

An example to do in your head

In the example above, I deliberately used numbers than were hard to manipulate in your head.  (Well, at least, they were hard to manipulate in mine ;-)

So here’s a really simple formulation of a similar problem, just so you can convince yourself than I’m not talking rubbish:

Again, imagine a project at the half-way point.  This time, the team has done exactly one third of the work, i.e. 33%.  Think of it this way: in their progress to date, they have done one on third of the work in half the time.  To finish on schedule, they must now do two thirds of the work in the other half of the time.  They must do twice as much work in the same amount of time – a 100% increase in speed.

Conclusion

Teams can’t speed up by 84% or 100%.  It just doesn’t happen. (At least, not when holding costs constant – and generally, not even when spending extra.)

When projects fall behind, our intuition lets us down. We have to rely on sound data and analysis instead.  I believe the best answer is to use Earned Value analysis.  A simple Earned Value chart like this goes along way to correcting our faulty assumptions.

Thanks for the generous re-print policy of Software Tech News, here is a copy of the article:

EarnedValueForAgileProjects.pdf

(If you are looking for the same material, but addressed to an agile audience rather than an ANSI/EIA-748 audience, see ‘Agile Charts‘.)

The charts can accommodate change in three ways, as follows:

Option 1: Chart against Current Scope Only

I like to show “percentages relative to what we know now“.   Features completed (the green line) are measured relative to the scope as it stands right now.  The budget (red) line is relative to the budget as it stands right now.

Contrast that with cumulative flow diagrams.  They do an excellent job of showing scope changes over time.  A cumulative flow diagram might show that, “We were doing OK until 3 weeks ago, and then we had that big scope increase, so now it looks like we’re way behind. But we haven’t been slacking – see, our rate of progress was fine for the old scope.”

With time and budget charts, that historical “excuse” is not shown.  People want status, not excuses.  So the chart measures everything against the most up-to-date scope and budget.  Our position relative to today’s target matters far more than our position relative to a target which is now obsolete.  In many respects I don’t care whether we were on track before the scope change – the scope has changed and I care whether we’re on track now.

Note that if scope increases, the green line effectively pivots downwards by a few degrees.  Its bottom end stays at (0, 0), but its slope lessens, since the work it shows now makes up a smaller percentage of the total.  For instance, consider this graph:

After a scope increase, it will look like this:

The green line has retained its shape, but has pivoted down because it represents a smaller percentage of the (new) scope.  The red and grey lines are unchanged, because the budget and schedule were not altered in this example.

Option 2: Enhance the Charts to Show Scope Change

If you want to, you can show historical targets as old versions of the grey line.  This graph has two versions of the grey line:

One grey line (the upper one) is the current target.  The other grey line peaks at a lower level and an earlier date.  It is the previous target. The date of its peak is the originally-scheduled completion date. The percentage at its peak represents the original scope, as a percentage of the current scope.  As you can see, until week 5 the project was on track to hit the original target.  Now, the new target gives the team a lot more scope (and a little more time). They have to increase their rate of progress if they are to meet the new target.  You can see them trying to do so, with the upwards kink in the red line.  The upward kink is probably due to overtime and/or some additional team members.

(By the way, the little bubbles to label things aren’t just for this page – they’re handy on real-life charts too.)

To reiterate, all the lines are percentages relative to the current scope and budget.

You can also show old targets with points instead of lines.   If you have several old targets, you might try something like this:

The little diamonds show all the “historical” points where the grey line used to hit 100%.   All are relative to the current scope.  Each is labeled with the date at which it became the current target.  In this hypothetical example we see that, on 1 March, we thought that the project was only 50% of its current size and that it would be completed on 26 April (we get this date from the X-axis position of the 1 March diamond).  On 15 March, the scope increased slightly and the delivery date remained the same.  We had additional increases on March 22 and 29, slipping the deadline by a week and taking the scope up to 85% of what we have today.  Finally, on 12 April, the scope was increased to the current 100% level, and the deadline was slipped by one more week.

I like the way this chart shows the “path” of historical targets moving through the coordinate space of the graph. But I must admit I don’t actually use this chart on my own projects. I prefer simple charts that show one old target at most.

Option 3: Add a Scope History Chart

Unlike me, many people do want to show several old targets.  If you’re one of those people, you may encounter a problem with Option 2.  While the little diamonds show scope change well, they can’t show budget changes too (if the budget changes are out of sync with the scope changes).  For instance, perhaps management increase scope by 10%, but still hope to complete the work within the original budget.  If that happens, you can’t use the diamonds for both scope and budget.  You have to use them for just one or the other.

I can’t see a way to solve that problem… but perhaps we don’t have to.  We don’t have to limit ourselves to just one chart.  Why not use two, a time and budget chart for the current status plus another chart for the history of scope change?

The first chart, the time and budget one, would be exactly according to Option 1 above.  How should the second chart look?  Very simple, I think.  Here’s a very basic Scope History Chart:

The planned scope is on the left, and the current scope is on the right.  In this example, we originally planned to build features worth $300k.  Now, we expect to build features worth $350k since, although we’ve dropped $30k of the original features we’ve added $80k of new features.

I haven’t actually shown budget figures directly on this chart.  Instead, I’ve simply drawn the graph so that the y-axis is in dollars.  You can relate past and present budget targets directly to the y-axis.  (We can’t do the same on a time and budget chart because everything there is expressed as percentages of the current targets.)

Many variations are possible.  For instance, you might show the scope as it was at several times in the past.  Like this:

Finally, you might add an “actual cost” column to the right hand side.  Note that, if you haven’t finished the project yet, the “actual cost” must be your best prediction of what the final cost will be.  “Trend lines”, on your time and budget chart, will help you make that prediction.

Here’s an example of a Scope History Chart, with actual costs shown in red.  (To save space, I’ve shown only two blue-grey bars. You can have more, as in the chart above, and then add the red cost bar onto the right-hand side.) Here’s the example:

Note that this chart directly shows scope creep and effort creep.  Scope creep is the difference between the original planned scope and the new planned scope. Effort creep is the difference between the new planned scope and the actual cost.

(If you’re working under a fixed price contract, the customer will pay for scope creep but not effort creep.  In that case, you should draw the red bar not to show what the customer actually pays; but rather to show what they would pay, if they paid for every hour worked on the project. That gives you a true measure of actual effort.)

Total creep = scope creep + effort creep. Total creep is the difference between the originally expected effort and the final actual effort.

What Do You Want To Show?

When choosing charts, there are so many things you might want to show.  They include velocity (rate of progress), progress compared to current scope, actual costs compared to budget, actual costs compared to progress made, history of scope change, history of budget change, history of schedule change, lead time and work-in-progress.

I doubt you can fit all of them on a single chart!  Fortunately, you don’t have to.  You can cover most of them with two charts: a Time and Budget Chart and a Scope History Chart.

• Are we on time?
• Are we on budget?

Gantt charts overshadow the big picture with details.  Here’s a clearer, simpler chart:

The dotted gray line is the target.  In this example, the project is 10 weeks long.  Each week we expect to complete 10% of the work and use up 10% of the budget.  That’s the ideal scenario.  Of course, the real world is different — that’s why we need the other two lines.

• The red line shows how much of the budget has been “burned”.  It is based on actual hours worked by the team.  In this example, we are three weeks into the project and we’ve burned 40% of the budget.
• The green line shows “percent complete”.  It’s based on features completed so far.  In this example, only 20% of the features are complete at the end of week 3.

Our sample project is in trouble.  We should have used 30% of the budget to complete 30% of the features, but instead we’ve used 40% of the budget to complete 20% of the features.  At least we’ve received the bad news early, while we still have time to do something about it.

More Examples

Let’s look at some projects that aren’t in so much trouble.

In Project B, the team’s progress (the green line) is lower than expected.  We can easily see the reason: the hours worked are low too.  Perhaps team members are being sidetracked by other projects.  On a more positive note, the percent completed is closely tracking the budget burned.  If things continue like this, the project will be late, but it won’t blow the budget.

In Project C, the team is doing really well.  After a shaky start, they’re now making great progress, under budget and ahead of schedule.   I’ve added trend lines to the chart, projecting that the green line will hit 100% two weeks ahead of schedule.  At that time, the red line will around the 85% mark — i.e. 15% under budget.

Questions

What are these charts called?

I like the name “Time and Budget Charts”, because they answer both questions:

• Are we on time?
• Are we on budget?

Who Uses Them?

Similar charts are popular throughout the agile community, although I’ve yet to see one with a budget burn line.  That may be due the popular misconception that agile projects can’t have fixed budgets.  In actual fact, agile projects can have fixed (or flexible) target budgets.  If you have a target budget on your project, I believe you should include the budget burn line.

Even if your budget is just a target or an expectation – not a fixed price in any way – you will still find it helpful to chart the budget burn.

Without the budget line, you can’t meaningfully relate progress to effort expended.  Are you running late due to underestimation or under-resourcing?  Are you on time, but only because the team is working overtime?  Without the budget line, it’s hard to tell.

Outside the agile community, we see very similar charts called “earned value charts”.  Earned Value Charts have the same three lines, but:

• The vertical axis is usually in dollars, so the three lines have slightly different names.  I prefer to use percentages because they’re easier to explain.  You can convert from one to the other just by multiplying or dividing by the total project budget.
• Earned value charts are generally presented in a more complicated, mathematical way as part of the broader discipline of Earned Value Management (EVM).

Because of these differences, I’ve invented the name “Time and Budget Charts” for the simplified versions shown here.  I suspect EVM practitioners would be rather offended by any suggestion that my simple summary adequately describes their work!  [Or maybe not]

By the way, Earned Value Management is popular in serious places like NASA and the US Military.  If you’re familiar with EVM, you’ll note that my three lines correspond to the EVM acronyms as follows:  green = BCWP; red = ACWP; grey = a linear approximation of BCWS.  Personally, I find the acronyms much harder to understand (and explain) than the simpler definitions I use on this page.

How do you keep them up to date?

For the green line, I drive it off the list of “all the things we have to do”. You probably have one already: a fine-grained feature list, a Joel-style feature list with task breakdown, an agile iceberg list or a Scrum-style backlog list.

We estimate effort for each item in the list. When each item is completed (and only then) I mark it as completed.  This is first input: Yes/No completion status on each task.

The green line shows the total size of the completed tasks, as a percentage of the total size of all tasks.  It is based entirely on estimated task sizes.  Why?  For uncompleted tasks, estimated size is the only size we have.  So, for the percentage to be meaningful, we must compare apples with apples and use estimated size even for the tasks we have completed.

I update the red line every Monday morning, by entering the total number of hours worked on the project during the previous week.   This is the second (and last) input: total hours worked per week.

There is no breakdown of exactly which hours were worked on which tasks.  That information is difficult to (accurately) gather, and for the purposes of this graph, it adds no value since the graph shows aggregates anyway.

Don’t you need a Gantt chart too?

No.

What about Microsoft Project?

Software development guru Joel Spolsky puts it this way:

“The trouble with Microsoft Project is that it assumes that you want to spend a lot of time worrying about dependencies… I’ve found that with software, the dependencies are so obvious that it’s just not worth the effort to formally keep track of them.” [see also: critical path in agile projects]

Joel continues:

“Another problem with Project is that it assumes that you’re going to want to be able to press a little button and “rebalance” the schedule… For software, this just doesn’t make sense [in practice]… The bottom line is that Project is designed for building office buildings, not software.”

Joel is a former Microsoft employee, who worked on both Excel and Project.  He’s not alone in his views. Chris Peters, Microsoft’s Vice President in charge of Office, also said that Microsoft Project is more appropriate for managing the design of airplanes and buildings, rather than software. [1]

He’s right.

But you’ll never hear that from Microsoft’s sales department :-)

Conclusion

Time and budget charts are a fast, effective way to track your progress.  They rest on the proven foundations of Earned Value Management, they’re easy to create and maintain, and they tell you what you need to know.

See also this more detailed comparison to traditional EVM.

For some writing by other agilists on the same subject, check out this pdf by Glen Alleman and Michael Henderson, plus Mike Griffiths’ writing here.