Finished work is what measures adaptive progress, and neither effort spent nor tasks started will do. An item is complete against an agreed standard or it is not, and every forecast and every chart is built from the count of completed items over time.
This is a stricter test than a percentage complete, and that strictness is the point. Eighty per cent complete carries no verifiable meaning, whereas an item which has met a definition of done has been demonstrated, tested and integrated. The measurement is coarse and it is real.
The three charts and what each one hides
Burndown charts plot work remaining against time, falling towards zero. Readable at a glance, it also conceals additions, because an item finished and an item added cancel out and produce a flat line.
Burnup charts plot two lines, work completed and total scope. Completion rises, scope is drawn separately, and the gap between them is what remains. It takes longer to read and it shows what the burndown hides, since a rising scope line appears as scope growth and is not disguised as slow progress.
Cumulative flow diagrams plot the quantity of work in each state over time as stacked bands. Band width represents the amount of work sitting in that state, so a widening band means a queue is forming, and the horizontal distance across the bands is how long an item takes to cross the whole system from request to delivery. Queues are what it shows.
Both charts describe one project over seven cycles. The burndown shows a team that appears to stall and recover. The burnup shows that scope grew by sixty units in cycle four, which is a conversation about the backlog rather than about the team.
Which chart to reach for
Inside a single cycle, use a burndown, since scope is meant to be fixed there and a flat line genuinely does indicate trouble. Across a release, use a burnup, since scope will move and concealing that fact serves nobody. Where work moves through stages and the question is where it is piling up, use a cumulative flow diagram.
None of the three says whether what was built is any good. All three measure throughput of accepted work. Acceptance is a judgement made elsewhere, by someone examining the increment and deciding whether it does what the organisation wanted of it.
Flow measures, and what they add
Where work moves continuously and not in cycles, the useful measures concern time and not quantity.
| Measure | Definition | What it tells you |
|---|---|---|
| Cycle time | How long an item takes from the moment work starts to the moment it is done | How quickly the team converts started work into finished work |
| Lead time | How long from the moment an item is requested to the moment it is delivered | What a requester actually experiences, including the wait before anybody started |
| Throughput | Number of items finished per unit of time | The delivery rate, without depending on any sizing scheme |
| Work in progress | Number of items started and not finished | How much is being carried at once, which drives the other three |
Their relationship is close enough to be worth remembering. Average cycle time is roughly work in progress divided by throughput, which says that starting more things while finishing the same number makes everything take longer. That single result is the argument for limiting work in progress. It is arithmetic and not philosophy.
Reporting upward without a parallel report
In a hybrid organisation the failure mode is familiar. A team runs adaptively, a sponsor receives a predictive report, and somebody translates between the two every fortnight. That translation costs effort every fortnight, and it introduces error at precisely the point where the sponsor is least able to detect it.
Reporting the same measurements at a different resolution is the way out. Where the work will be is answered by a release burnup with a forecast range. What has been produced is answered by a count of delivered increments. What it has cost is answered by spend to date against the funding envelope. None of these requires the team to maintain a second set of numbers.
Where formal earned value is required, sized backlog items supply the measure of completion. Earned value is the budget for work actually completed, planned value is the budget for work that should have been completed by now, and both can be computed from a release baseline and a count of accepted items. The indices then mean what they always meant, and an adaptive project becomes reportable in the language a portfolio office already uses.
Radiators beat reports
An information radiator displays the current state of the work where anybody may see it without asking. A board, a chart on a wall, or a dashboard on a screen in the team area will all serve.
It earns the wall space. Anyone able to see the state of the work has no need to ask, and the team has no need to stop and answer. Any report somebody assembles is a snapshot of what was true at the moment of assembly, and it is already old by the time it is read.