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.17560770

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.


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 most EVM practitioners would be rather offended by any suggestion that my simple summary adequately describes their work!

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?


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 🙂


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.

[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”.

10 comments on “Agile Charts

  • The problem with this seemingly nice and neat “time and budget charts” is that you forget 2 things:
    1. Agile does not have set requirements, they can change depending on the desires of the owner/owner’s rep (according to Agile Values and Principles)
    2. Without set requirements, how can you draw you very nice and neat “grey line” labeled “planned value?”

    According to Agile Value and Principles, there is no such thing as “on budget” or “on plan” (see the Agile Manifesto 4 Guiding Values). You premise and flawed and therefore of little value in “Charting Agile.” Good try, though.


  • Hi Paul,

    Interesting you should comment on this today. Just yesterday, I gave a talk that covered the points you raised. I’m afraid I covered them in the talk better than I have in anything I’ve written on this site. Hopefully, I’ll be able to post the talk online one day.

    In the meantime, here are a number of points in response to yours:

    1. Earned Value handles change just fine. I wrote about that here: http://www.agilekiwi.com/earnedvalue/charting-change/ . In agile terms, Earned Value’s green line is just velocity, and no-one says that velocity is invalidated by scope changes.

    2.To use Earned Value, you do need some kind of rough scope for the whole of the project. In XP terms, this would be a set of epic user stories. In FDD (another “flavour” of agile) it would just be the usual FDD feature list. In agile, making a list like this at the start of the project is _optional_. (Your comments imply that it’s _banned_, which is not the case for most flavours of agile). So, if you make such a list, you should use EV; if you don’t, you shouldn’t. [See the opening pages of this article for more details: http://www.agilekiwi.com/earnedvalue/agile-charts-part-ii-the-evm-perspective/ ]

    3. You mentioned the agile manifesto. I don’t see anywhere where is says there is no such thing as “on budget” or “on plan”. What I do know is that one of the co-authors of the manifesto promotes something that is _exactly_ the same Earned Value’s green and grey lines. See Alistair Cockburn’s site, here: http://alistair.cockburn.us/Earned-value+and+burn+charts . Alistair has been supportive of “my” “innovation” of adding the budget burn line, quoting my site both on the above page and in the 2nd edition of his Agile Software Development book. (Sorry about the name-dropping. Just wanted to reassure you that I’m not a lone nutter 😉

    I apologies for being unable to explain the above points more fully right now. Hopefully I’ll get around to a new blog post on the topic one day. In the meantime, I strongly (but respectfully) refute your suggestion that the premise is flawed 😉



  • Pingback: Apples and Oranges
  • I every time spent my half an hour to read this webpage’s content daily along with a
    cup of coffee.
    Most are lactose free, some have additional fiber,
    and some are exclusively intended for youngsters or adults with particular well being challenges.
    Superior tension combatant in the course of moments
    of high panic.

Comments are closed.