How to Read a Burn-up Chart in a PMP Scenario

A burn-up chart usually appears at the moment in a status meeting when someone wants to know whether the date still holds. Attention goes straight to the rising line, because rising looks like progress, and progress is what everyone came to hear about. That instinct is the reason burn-up charts are so often misread. The line that carries the news is normally the other one.

The chart plots two things against the same time axis. The lower line is cumulative work completed, growing as items are finished. The upper line is total work currently in scope. The vertical gap between them at any point is the work remaining, and a forecast comes from extending the completed line at its present slope and seeing where it would meet the scope line. The unit can be story points, features, requirements, test cases, tasks or finished physical items. Which unit is used matters less than whether everyone counting agrees what finished means, because the whole chart inherits that definition.

What the scope line is telling you

The scope line is the reason a burn-up exists as a separate artefact. A burn-down shows remaining work as a single quantity, so a flat burn-down is genuinely ambiguous: the team may have delivered nothing, or it may have delivered a fortnight of work while an equivalent amount arrived from somewhere else. Those two situations need completely different responses, and a burn-up keeps them apart by refusing to net them off. Where the difference between the two chart types is the actual question, that comparison is covered separately.

So the scope line is where a reader should look first. It moves in steps rather than smoothly, and each step has three properties: a date, a size, and a reason. Only the first two are on the chart. The reason has to be retrieved from the backlog, the change record or the person who raised it, and it is the reason that determines what a project manager should do next.

Steps arrive from several sources that look identical on the page. Work may have been decomposed rather than added, so items that were always implied have become visible and countable for the first time. A genuinely new requirement may have been introduced. Work may have transferred in from another team or another phase. An early estimate may have been corrected once the team understood the domain properly. Occasionally the unit itself has been recalibrated, which is a measurement change wearing the costume of a scope change and is the one worth catching early.

Burn-up and burn-down charts sit among the tools and techniques set out in Section 5 of the PMBOK® Guide, alongside other visual delivery measures. The orientation there is a useful one to keep: a technique supports judgement rather than supplying the answer, which for a burn-up means the chart tells you that something changed and when, and leaves the interpretation entirely with you.

A reading order that prevents the obvious mistake

Working through the chart in a fixed order stops the rising line dominating the conversation.

1. Confirm the unit, and whether the counting convention has been stable across the whole period shown.
2. Look at the scope line. Has it moved, when, and by roughly how much each time?
3. Look at the slope of the completed line. Is it steady, decaying, or lumpy in a way that suggests batching rather than flow?
4. Extend both lines and see where they cross, then compare that to the date the organisation actually cares about.
5. Only then decide what kind of problem you are looking at.

The absences matter as much as the lines. A burn-up says nothing about quality, so work counted as complete may be carrying defects that will return as new items later. It says nothing about partially finished items, which either sit uncounted or get counted generously depending on team culture. It assumes the remaining work resembles the work already done, which is frequently untrue on projects where the awkward integration items have been deferred to the end. And it cannot see dependencies outside the team, so a team can be perfectly on trend and still miss the date because a third party has not delivered.

Iteration eight, and a scope line that moved twice

A local authority is replacing its licensing system across fourteen two-week iterations. At the end of iteration eight, the completed line has a steady slope with only minor variation. The scope line has stepped twice, once at iteration three and once at iteration six, and the second step was the larger of the two. Projecting both lines forward, the crossing point now sits around two iterations beyond the committed go-live. The delivery team's proposal is to add two developers.

The chart argues against that as a first move. The slope has not deteriorated, so the team is not slowing; the target has moved away from them. Adding two people to a team of seven at iteration eight is unlikely to lift the slope inside the remaining time, and may lower it briefly while the new people are brought up to speed. The more useful action is to go behind the two steps and find out what was added and why.

Suppose the iteration three step turns out to be decomposition. A single backlog item covering historic record migration was broken into eleven items once the team saw the actual data. Nothing new was requested; the work was always required, and the original figure was simply wrong. That is a forecast correction and an estimating lesson, and it belongs in a conversation about the credibility of the remaining estimate rather than about resourcing.

Suppose the iteration six step is different: a payments integration requested directly by a service manager, accepted by the team as reasonable, and never taken through any decision anywhere. That is a scope decision the sponsor has not been asked to make, and it is now embedded in the forecast as though it were agreed. The two steps sit on the same line and look the same, but one needs a re-plan and the other needs an authorisation conversation, possibly a difficult one. If you want to build that kind of reading habit across the wider syllabus rather than one technique at a time, PMP® Exam Preparation works through the same interpretive discipline applied to schedule, cost and risk information.

The same chart on predictive and hybrid work

Burn-up charts are usually introduced as an adaptive tool, which leads people to assume they only belong on iterative delivery. The underlying idea is more portable than that. Any project counting comparable units of completed work against a known total is drawing a burn-up whether or not it uses the name: meter installations against the programme total, sites commissioned, drawings approved, test cases passed, records migrated. On predictive work the scope line should move rarely, and when it does move it should correspond to an approved change, which makes an unexplained step a governance signal rather than a delivery one.

The technique breaks down where units are not comparable. If one remaining item carries most of the technical risk, a chart showing ninety per cent completion is actively misleading, because the last ten per cent is not ten per cent of the difficulty. It is also not a substitute for earned value, which relates work performed to planned cost rather than counting scope units. The two answer different questions and can sensibly appear in the same status pack.

For a PMP candidate, the important distinction is between a chart that reports a slope problem and a chart that reports a scope problem, because scenario questions tend to give you the chart as context and then test what you do about it. Preparation material sometimes leaves candidates with a reflex that any schedule concern should be answered by compressing the schedule or adding resource, and that reflex is what a burn-up is well placed to interrupt. The habit worth building is to identify which line moved before choosing a response, and to notice when the answer requires information the chart does not contain.

On a real project, the chart earns its place mainly because it makes a conversation possible. Scope growth is hard to argue about in the abstract and quite hard to deny when it is drawn as a series of dated steps above a steady delivery line. That only holds if the definition of done is honest and the scope line is genuinely maintained. A burn-up kept properly is one of the more useful things you can put in front of a sponsor. A burn-up kept loosely is a picture of optimism with a time axis.

Andre Malowney

Interested in going further?

Reading a chart correctly is a small skill inside a larger one: working out what a piece of project information is actually reporting before deciding what to do about it. Structured preparation gives you that habit across schedule, cost, risk and stakeholder information rather than one technique at a time, which is what scenario-based questions and real status meetings both reward.

The Eighth Edition places burn-up and burn-down charts among its broader tools and techniques material, which is useful if you want to see where visual delivery measures sit alongside estimating, forecasting and earned value.

Ad · Amazon affiliate link.

References

A118: Burn-up vs Burn-down Charts
A180: Facilitation Techniques for Difficult Project Conversations
A161: Expected Monetary Value Explained
A187: Retrospectives That Lead to Change
A178: SWOT Analysis in Project Management

PMP and PMBOK are registered marks of the Project Management Institute, Inc.