8.5 The Progress Practice in an Agile Context

8.5 The Progress Practice in an Agile Context

Quick summary: The progress practice monitors and compares what has been delivered with what was planned, forecasts the outturn, and controls any deviations causing an exception. In an agile project, progress is measured by working product meeting the Definition of Done — the only measure that cannot be inflated.

Purpose

The purpose of the progress practice is to establish mechanisms to monitor and compare actual achievements against those planned, to provide a forecast of the project's objectives and continued viability, and to control any unacceptable deviations.

Two phrasings recur in exam questions and are worth memorising verbatim:

• "By comparing what has been delivered with what was planned" — this identifies progress in a purpose question.
• "A purpose of the [ ? ] practice is to control any deviations causing an exception" — the missing word is progress.

Why working product is the honest measure

The traditional measure is percentage complete, and it is unreliable for a well-known reason: it is self-reported against work that cannot be independently inspected. The "90% complete" that stays 90% complete for two months is a standing joke because the last increment of effort is where all the unknowns live.

Agile replaces it with a binary test at item level. An item either meets the Definition of Done or it does not; there is no partial credit. That makes progress:

• Objective. The Definition of Done is written down and checkable.
• Non-inflatable. You cannot claim eight-tenths of done.
• Meaningful. Completed items are usable, so completion corresponds to value rather than to effort expended.

Aggregate that across an iteration and you get velocity; plot it and you get a burn chart; publish it and you get a dashboard.

What progress is measured with

The burn-up chart is preferred at release and stage level because it draws total scope as a separate line, so scope flexing is visible rather than concealed — which matters precisely because scope is the variable that flexes.

Tolerances and exceptions

Progress is the practice through which manage by exception operates.

Tolerances are set for each performance target — benefits, cost, time, quality, scope, sustainability, risk — at each level of the project. Within its tolerance, a level acts without referring upward.

The delegation cascade:

When a level forecasts that it will breach its tolerance, it raises an exception to the level above. Note the word: the trigger is the forecast, not the actual breach. Waiting until the tolerance has already been exceeded removes the level above's ability to act.

A tolerance is not a target and not a buffer to be consumed. It is the limit of delegated authority.

Time-driven and event-driven controls

The distinction is simply what triggers the control: a date for time-driven, a circumstance for event-driven.

Tailoring progress for agile

• Reporting shifts from push to pull. A live dashboard the board can consult at any time is better than a weekly document, because it is current and it costs the team nothing to produce.
• Reports become thinner, not absent. The highlight report still exists; it summarises tolerance consumption, forecast, exceptions and benefit position, drawing on data the team generates anyway.
• Forecasting uses velocity rather than remaining-effort estimates.
• Progress is reviewed at multiple cadences: continuously by the team, at each iteration review, at the progress review workshop, and formally at each stage boundary.

The governing intent is that reporting should be a by-product of delivery, not a separate activity performed for the benefit of management. When a team spends a day a fortnight producing a report nobody reads, the progress practice has been implemented badly.