Tracking adaptive progress means measuring how much finished work a team has produced over time and forecasting from it. Finished work is the only input. 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. The Agile Practice Guide describes the charts and measures, and the examination tests whether a candidate can read them and can report from them to a sponsor who expected a predictive report.
This is a stricter test than a percentage complete, and that strictness is the point. Eighty per cent complete carries no verifiable meaning, and an item that has met a definition of done has been demonstrated, tested and integrated. The measurement is coarse and it is real. The sections below cover the three charts, which one fits which question, the flow measures, how the same figures are reported upward and why a radiator beats a report.
The three charts and what each one hides
Burndown charts plot work remaining against time, falling towards zero. Readable at a glance, a burndown 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, since the team was never the problem.
Which chart fits which question
The three charts answer three questions. Inside a single cycle, a burndown is the right chart, since scope is meant to be fixed there and a flat line genuinely does indicate trouble. Across a release, a burnup is the right chart, since scope will move and concealing that fact serves nobody. Where work moves through stages and the question is where it is piling up, a cumulative flow diagram is the right chart.
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.
The four flow measures
Where work moves continuously, the useful measures concern time, and there are four.
| Measure | Definition | What it says |
|---|---|---|
| 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, and it is arithmetic, so it admits no argument.
Reporting upward without a parallel report
Charts and measures are read by the team, and the sponsor usually wants something else. 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.
Information radiators
The last question is where all of this is displayed, and the answer is somewhere anybody can see it without asking. An information radiator displays the current state of the work in the open. 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.