Adaptive progress is measured by finished work rather than by effort spent or tasks started. An item is complete against an agreed standard or it is not, and the count of completed items over time is what every forecast and every chart is built from.
That is a stricter test than a percentage complete, and it is the point. A task reported at eighty per cent has no verifiable meaning, whereas an item that 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
A burndown plots work remaining against time, falling towards zero. It is readable at a glance and it conceals additions, because an item finished and an item added cancel out and produce a flat line.
A burnup plots 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 the thing the burndown hides, because a rising scope line is visible as scope growth rather than disguised as slow progress.
A cumulative flow diagram plots the quantity of work in each state over time as stacked bands. The width of a band is the amount of work sitting in that state, so a widening band is a queue forming, and the horizontal distance across the bands is how long an item takes to cross the whole system.
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
Use a burndown inside a single cycle, where scope is meant to be fixed and a flat line genuinely does indicate trouble. Use a burnup across a release, where scope will move and hiding that fact serves nobody. Use a cumulative flow diagram where work moves through stages and the question is where it is piling up rather than how much is left.
None of the three tells you whether what was built is any good. They measure throughput of accepted work, and acceptance is a judgement made elsewhere by somebody looking at the increment.
Flow measures, and what they add
Where work moves continuously rather than in cycles, the useful measures are about time rather than 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 |
The relationship between them 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, and it is arithmetic rather than philosophy.
Reporting upward without a parallel report
The failure mode in a hybrid organisation is a team that runs adaptively and a sponsor who receives a predictive report, with somebody translating between them every fortnight. The translation costs effort and introduces error.
The way out is to report the same measurements at a different resolution. A release burnup with a forecast range answers where we will be. A count of delivered increments answers what has been produced. Cost to date against the funding envelope answers what it has cost, and none of those require 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 is a display that shows the current state of the work where anybody can see it without asking. A board, a chart on a wall, a dashboard on a screen in the team area.
The reason it is worth the wall space is that it removes the interruption that produces most status reporting. Somebody who can see the state of the work does not need to ask, and the team does not need to stop and answer. A report that somebody assembles is a snapshot of what was true when they assembled it, which is already old when it is read.