Agile Charts

I’m sick of Gantt charts.  They’re hard to maintain and they don’t tell me what I want to know.  I want the big picture:

• 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 haos.com">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.

---

Note: These charts are not limited to fixed-scope projects.  See Charting Change.

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.

For a simple agile tool, which implements these charts exactly as described here, check out Tactyle. 

---

[1] Chris Peters, formerly Vice President in charge of Microsoft Office.  Interviewed in 1993 and 1994 for the book Microsoft Secrets.  See chapter 4 of that book, under the heading "Tracking and Announcing the Ship Date".