7.2.2: Visual Metrics- Burndown, Burnup, and Cumulative Flow

Burndown Chart

A burndown chart shows remaining work over time, and it's most commonly used during a Sprint or a release to track how much is left to complete. If the line trends steadily downward, work is genuinely being completed at a healthy pace. If the line stays flat for several days, work may be blocked, too large to move quickly, unclear in its requirements, or simply not making its way to done despite effort being spent on it. If the line ticks upward instead, new work has likely been added mid-Sprint, or existing work has been re-estimated to reflect newly discovered complexity.

A burndown chart is genuinely useful, but it can also be quietly misleading if read too literally. A team might show a beautifully declining burndown while quality is actually suffering underneath it, or the chart might sit flat for days simply because work is nearly finished but hasn't yet been formally accepted. A burndown chart should always trigger a conversation rather than panic. A good Agile response to a flat burndown sounds like "let's inspect why work isn't moving to done." A poor response sounds like "everyone must work overtime," which treats a system signal as a personal failing.

Burnup Chart

A burnup chart shows completed work over time, and it often displays total scope alongside it, which makes it especially valuable whenever scope is shifting. A burndown chart can show remaining work shrinking, but it doesn't always make clear that the total amount of work has actually grown behind the scenes. A burnup chart captures both progress and scope growth on the same picture, so nothing gets hidden in the gap between the two lines.

Imagine a team completing work at a steady, healthy pace while stakeholders keep quietly adding new scope along the way. A burnup chart can show clearly that the team isn't failing to deliver at all. The target itself is what's moving. This tends to produce a much healthier stakeholder conversation: "we're completing work steadily, but scope is increasing faster than completion, so we need to talk through priority, date, or scope tradeoffs together." Burnup charts earn their usefulness by showing progress and change side by side, rather than forcing a team to explain scope creep after the fact.

Cumulative Flow Diagram

A cumulative flow diagram, or CFD, shows how work moves through workflow states over time, typically using colored bands to represent steps such as Ready, In Progress, Review, Testing, and Done. The width of each band at any point in time shows how much work currently sits in that state, and a band that keeps widening is a direct signal that work is piling up in that step rather than moving through it.

If the Testing band keeps growing wider, for instance, testing is becoming a real constraint on the whole system. The right response isn't to keep pushing more work into an already overloaded step. It's to ask why testing has become the bottleneck in the first place. Possible causes might include unclear acceptance criteria, testing happening too late in the process, too many defects surfacing at once, too few people with the right testing skills, work items that are simply too large to test quickly, unstable test environments, or a lack of automation covering repetitive checks. A cumulative flow diagram earns its place among Agile's most powerful tools precisely because it makes flow problems visible at a glance, helping the team see exactly where work is getting stuck rather than guessing.

Risk Board

A risk board makes risks visible rather than letting them live only in someone's memory or a document nobody opens after the first week. Agile teams should manage risk continuously rather than treating it as a one-time exercise, and a risk board is what makes that continuous management practical day to day.

A risk board can hold product risks, technical risks, dependency risks, compliance risks, quality risks, security risks, adoption risks, and delivery risks all in one place. For example, a risk entry might read: risk, a security review may delay release; probability, high; impact, high; owner, the Product Owner together with a security liaison; response, engage the security reviewer during refinement, identify high-risk stories early, and run a spike for any uncertain controls; status, active. The real value of a risk board isn't the paperwork. It's visibility, since a risk the team can see is a risk the team can act on well before it becomes an incident.

Impediment Board

An impediment board shows blockers that slow or stop the team outright, and naming them clearly is often the first step toward removing them. Common examples include missing access to a needed system, an unavailable environment, a delayed approval, an unclear requirement, a dependency on another team, unstable test data, a stakeholder who's hard to reach, a tool issue, or a production incident pulling attention away from planned work.

A good impediment board shows not just what's blocked, but who owns resolving it, what action is currently being taken, and whether the impediment needs to be escalated further. This kind of board is especially useful for Scrum Masters, Agile coaches, and servant leaders, since it helps them remove barriers as they appear and, just as importantly, notice recurring patterns that point to a deeper systemic problem worth addressing directly.

Dependency Board

A dependency board shows work that depends on other teams, systems, vendors, approvals, or decisions outside the team's direct control. Dependencies are dangerous for two reasons at once: they create waiting, and they create false confidence. A team can genuinely believe its own work is on track while the larger delivery is quietly at risk simply because another team, somewhere else, is running behind.

A dependency board typically tracks the dependency description, the owning team, the date the dependency is needed by, its current status, its risk level, the escalation path if it slips, and any mitigation plan already in motion. This kind of board becomes especially valuable in larger Agile environments where several teams have to coordinate closely, since it's often the only place where those cross-team risks are visible to everyone who needs to see them.

PMI-ACP Exam Connection

If a chart in a PMI-ACP scenario shows a problem, the best answer is almost always to inspect the cause together with the team rather than react to the chart itself. The team shouldn't be punished simply because a chart looks bad, the chart shouldn't be hidden from stakeholders to avoid an uncomfortable conversation, and overtime shouldn't be the first response reached for. Visual metrics exist to create transparency, and the right next step after that transparency is always to adapt based on what the team actually learns from it.