8.6 Progress Artifacts and Techniques: Burn Charts and Dashboards

8.6 Progress Artifacts and Techniques: Burn Charts and Dashboards

Quick summary: Dashboards — team and project — are the primary agile progress artifact. Burn charts visualize the trend; burn-up charts are preferred where scope flexes. The progress review workshop is where progress is inspected collaboratively. PRINCE2's reports survive, thinner and drawn from data the team already generates.

Dashboards

A dashboard is a visual, at-a-glance display of current status designed to be read rather than studied. PRINCE2 Agile uses two.

The team dashboard

Shows the delivery team its own state, and is established in the kickoff workshop:

• Work in progress and where it is queuing
• Blockers and impediments
• Burn-down for the current iteration
• Definition of Done compliance and defect counts
• Team agreements, values and norms

Its audience is the team itself. Its purpose is to let the team self-manage — a team that can see its own bottleneck fixes it without being told to.

The project dashboard

Shows the project manager and the project board where the project stands:

• Progress against the release map
• Tolerance consumption for each performance target
• Top risks and open issues
• Benefit forecast against the business case
• Quality position and technical debt trend

Maintaining the information held on project dashboards is a named project responsibility — this is not something that maintains itself, and a stale dashboard is worse than none, because it is trusted while being wrong.

Information radiators

An information radiator is any highly visible display of information that broadcasts status continuously to anyone who passes it — a physical board, a wall-mounted screen, a shared page.

The principle behind them is that status should have to be noticed, not requested. In a traditional project, a stakeholder wanting to know how things are going asks the project manager, who assembles an answer — a cycle costing days and producing an answer already out of date. A radiator inverts this: the information is always there, always current, and available to everyone at the same time.

This connects directly to transparency as a characteristic of the agile mindset, and it depends on psychological safety: a team that fears the consequences of visible bad news will find ways to make the radiator show green.

Burn charts

Covered in section 3.2 and repeated here because they belong to this practice.

The reason burn-up charts matter more in a PRINCE2 Agile project bears repeating: scope is the performance target that flexes, so governance needs to see the flexing. A burn-down chart absorbs added and dropped scope into a single line, leaving the board unable to tell a slow team from a growing scope.

Cumulative flow diagrams serve the same purpose in flow-based delivery, showing how much work sits in each state over time and therefore where work accumulates.

The progress review workshop

The progress review workshop is the collaborative forum in which progress is inspected and next steps agreed. It brings together the people who hold the information — the project manager, the product owner, the team, and the relevant board members — to look at the same evidence at the same time.

Its advantage over circulating a report is that questions can be answered in the room. A board member who does not understand why velocity has dropped can ask, and the answer can be given by the person who knows. It is also where the release map is re-tested against actual delivery, and where trade-offs — flexing scope, re-sequencing releases, escalating an exception — are agreed with everyone present.

The reports that survive

Agile does not abolish PRINCE2's reporting; it changes how the content is produced.

The design intent throughout: reporting should be a by-product of delivering, not a parallel activity. If producing the highlight report requires the team to stop working and gather information that does not otherwise exist, the dashboards are not doing their job.