PMI-ACP Visualize Work: Kanban Boards, Burndown and Burnup Charts, and Cumulative Flow Diagrams

Visualizing work means showing every piece of a team's work, and the state each piece is in, in one place everyone can see, so the team and its stakeholders can spot problems and decide from facts instead of from memory or status reports. The usual tools are a board (a Kanban board or an iteration task board) and a small set of charts drawn from the same data: burndown charts, burnup charts and cumulative flow diagrams.

The PMI-ACP Examination Content Outline lists Visualize work as a task in the Product domain, with three enablers that give this lesson its structure:

1. Educate work visualization techniques. Help the team, and the people around it, design boards that show the real work and read charts correctly.
2. Establish a process to update the data/stats. Agree who updates the board, when a card moves and what gets recorded, so the statistics reflect reality.
3. Continuously share information. Keep the picture current and let each audience see the view it needs, drawn from the same live data.

The three depend on each other. A board nobody understands is decoration; a board that is understood but updated late misleads; and accurate data that only the team can see does not help the sponsor who is about to make a decision. A visualization earns its place when it answers a question someone actually has: what should we finish next, where is work piling up, how much is left before the release goal is met?

Two neighbouring tasks are taught in their own lessons. Information radiators as a transparency practice, impediment visibility and the misuse of velocity belong to Build transparency; choosing and analysing delivery metrics, and using WIP limits to optimize flow, belong to the Delivery domain. Here, WIP limits appear only as something a board shows.

A board's columns should show the steps a team's work actually goes through today, including the steps where work waits, so that the position of a card tells the truth about that work. Columns represent workflow states. They do not represent people, priority levels or iterations; those are shown, if needed, by swimlanes, card order, colour or labels.

Map the process you run, not the one on paper

A good way to find the real steps is to trace a handful of recently finished items and write down every place each one went and every place it sat. Where that trace differs from the documented process, the board follows the trace. A board drawn from a process document, or from the process the team would like to have, hides exactly the behaviour that needs improving. Once the real flow is visible, the team can change it deliberately and redraw the board to match.

Show waiting, not just working

A board with one broad active column (To Do, Doing, Done) is a common start, but it stops being informative once most cards collect in the middle: the column cannot say whether an item is being worked on or is sitting in a queue. Picture a content team whose In progress column hides drafting, waiting for legal approval and waiting for translation. Splitting the active column into each real step, including the waiting steps, shows where items actually sit. Waiting is usually where most elapsed time goes, and a separate queue column is also what allows a tool's timestamps to measure it later.

Done sub-columns make pull possible

In a push system, each step hands work on as soon as it finishes, whether or not the next step has room. Splitting a step into In Progress and Done sub-columns turns that hand-off into a visible queue of finished work. The downstream step pulls from the queue when it has capacity, so its WIP limit can hold, and the upstream step can see the queue growing and slow down. The overload becomes visible instead of being absorbed by the next step.

The team designs its own board

The people who do the work know its steps, so they design the board, with the practitioner facilitating: asking questions, offering techniques and letting the team decide. A board imposed from outside, however well designed, describes someone else's work, and people have little reason to keep it current. A board the team designed is one the team owns and keeps changing as its process changes.

When leaders need a consistent roll-up across teams, consistency comes from agreeing a few shared states (for example, Not started, In progress, Done) and having each team map its own columns onto them. Each team keeps its own board; the higher-level view aggregates the mapped states.

An iteration task board shows only the work the team planned for the current iteration and is cleared and set up again at each iteration's planning; a Kanban board shows continuous flow, with cards that keep moving across iterations and explicit WIP limits on its columns. Both are boards of the team's work; they typically differ in time horizon and in what limits the work.

The choice follows how work arrives and leaves. Where work arrives continuously and each item is released when it is ready, there is no iteration plan for a task board or an iteration burndown to describe; a continuous-flow board fits. Neither board shows the whole product backlog ordered by value; that is the backlog itself, covered in the Refine product backlog lesson.

A team that moves from timeboxes to continuous flow also has to give up the periodic reset. Cycle time measures each item's unbroken journey from the moment work starts to the moment it is done, so the board has to keep that journey intact: one continuous board on which unfinished cards stay where they are when an iteration boundary passes.

Everything the team spends capacity on belongs on its board, because work that is not visible competes for time unseen and makes the board unable to explain what the team delivers. The most common gap is unplanned work: production support, ad hoc requests from other departments, and improvement actions.

• Unplanned and support work. When a large and varying share of capacity goes to work the board does not show, delivery looks erratic and nobody can see why. Giving that work its own card type (or swimlane) shows how much capacity it takes, so the team and product owner can plan with real data. The principle is to make the cause visible on the board itself, not to compensate for it elsewhere.
• Classes of service. Not all work is treated the same. Expedite items, fixed-date items and standard work each need a distinct visual signal, such as a card colour or swimlane per class of service, and every fixed-date card shows its due date so the deadline is seen in time.
• Improvement actions. Improvement work needs capacity just like feature work. Putting each agreed improvement on the board as a card makes it compete openly for that capacity and come up in the same daily conversation as everything else.
• Shared specialists. A person or small group who serves several teams (say, a database administrator supporting four teams) needs one visible queue of everything requested. The requesting teams can see where their item stands, and the specialist has evidence for a conversation about priorities or capacity.

The test is simple: if the team does it, it is on the board. Making work visible is not the same as escalating it or giving it to one dedicated person; it is the step that lets everyone see the real load before deciding anything.

Educating work visualization techniques means helping people build and read the visuals they need, one at a time, so that each one informs a decision. It is coaching, not a training course on a tool's features.

Introduce charts when a question needs them

Charts introduced before anyone has a question for them tend to be ignored, and a large set introduced together buries the useful ones. Start with the board, and add a chart when the team or a stakeholder asks something that the chart answers. The chart then has a purpose and an owner, and the team learns to read it while it matters.

Match the chart to the question

Teach people to read the chart

A chart only helps the people who can read it. When someone misreads one, the practitioner walks them through it in context: what each axis measures, what the ideal or reference line means and what direction counts as progress. Doing this together, on the real chart, builds a shared picture; it is part of the practitioner's job, not a one-off handout.

Sometimes the better fix is a different chart: a burndown can make real progress look like no progress when scope is added, and a burnup shows the same facts without that trap (see the burnup section below).

A burndown chart plots the work remaining (in story points, stories or task hours) on the vertical axis against time on the horizontal axis, with an ideal line running from the starting total to zero at the end of the iteration or release. The actual line shows what really remains each day; its shape tells the team how the work is flowing.

Remaining work is a fresh estimate

When a team burns down task hours, the remaining figure for each task is re-estimated by the person doing it: how much is left now? Computing remaining work from the original estimate minus hours already spent measures effort, not progress, so the line falls on schedule whatever happens to the work. A rise in an honestly re-estimated burndown is useful information, not an error to smooth away.

Release burndowns and scope change

A release burndown shows the work left in a release. In its simple single-line form, completed work and added scope are netted together: in an iteration where the product owner adds more scope than the team completes, the line goes up and a reader may conclude the team did nothing. (Mike Cohn's alternative release burndown draws scope changes below the baseline to separate them.) When scope moves, a burnup shows the two facts most plainly.

A burnup chart has two lines: completed work, which rises as the team finishes items, and total scope, which moves only when work is added to or removed from the release. The release is done when the lines meet, so the gap between them is the work still to do.

Each line answers its own question. The scope line changes only when the release's content changes; the completed line changes only when work is finished. So a step in the scope line says something about scope decisions, not about the team's pace, and the team's pace is read from the completed line alone. Convergence depends on both: if scope grows as fast as work is completed, the gap stays the same size and the finish line keeps moving away, however steadily the team delivers. This separation is the main advantage of a burnup over a burndown.

Forecasting a range

Forecast from a burnup as a range, using the slowest and fastest velocity the team has actually shown, not a single figure from the average or the best iteration. Suppose total scope is 260 points, 100 are complete and recent velocity has run from 20 to 32. That leaves 160 points: 160 ÷ 32 = 5 and 160 ÷ 20 = 8, so the forecast is "between 5 and 8 more iterations". A range communicates uncertainty honestly and narrows as more iterations are completed.

When scope keeps growing

If scope rises steadily, the gap closes only at the difference between velocity and scope growth. Suppose scope is 150 points and grows about 6 points an iteration, 70 points are complete and velocity is about 22. The gap of 80 closes at about 22 − 6 = 16 points an iteration, so the lines meet in about 5 iterations; dividing the gap by velocity alone would promise about 4. Showing the trend lines on the chart lets the product owner decide whether to cap scope, reorder or accept the later date.

A cumulative flow diagram (CFD) plots, over time, the cumulative number of items that have reached each state of the workflow, with one coloured band per state, stacked from Done at the bottom to the first state at the top. Because the counts are cumulative, the lines never fall; a falling top line would indicate removed items or a data problem, not completed work.

To find a bottleneck, look for the band that keeps widening while the bands before it hold steady and the Done line loses slope: work is entering that state faster than it leaves, and everything downstream is starved. The diagram points at the state to investigate; the team then asks why.

Cycle time from a CFD

Little's Law links the three readings: on average, cycle time ≈ work in progress ÷ throughput, as long as the flow is reasonably stable. For example, if the vertical distance between the started and finished lines has stayed around 24 items and the finished line climbs about 3 items a working day, items take roughly 24 ÷ 3 = 8 working days from start to finish. The horizontal gap between the same two lines gives the same estimate visually. Cycle time is a duration, so it always needs both inputs.

Establishing a process to update the data means agreeing who moves cards, when they move and what is recorded on each item, so that the board shows the current state of the work and the statistics derived from it (cycle time, throughput, blocked time) can be trusted. It is a working agreement the team makes and keeps, not a reporting chore assigned to one person.

The person doing the work moves the card, at that moment

Each team member moves the cards for their own work as the work changes state. Any arrangement in which someone else updates the board on people's behalf, or updates it later, makes the board trail the real work, and the team then coordinates from stale information. Everyone who does the work therefore needs direct access to the board; for a distributed team that usually means an online board every member can update.

Record what the statistics will need

Flow statistics need dates. Cycle time needs the date each item started and the date it finished; throughput needs the finish dates. Teams on a physical board write these on the cards as they move, and a tool records them as timestamps. Lead time is a different, longer measure, taken from when an item was requested or committed to until it is delivered, so decide which question you want answered before choosing which dates to capture. Estimates and logged hours describe effort, not elapsed flow time. Blockers need dates too: recording when each block started and when it was cleared shows how much delay comes from outside dependencies.

Agree when a card moves

Tool timestamps are only as good as the moves behind them. Agreements that keep the data honest:

• Define entry to each column by one observable event, written on the board as a policy, so everyone moves cards at the same point in the work.
• Move cards as those events happen, one at a time, rather than catching up in batches.
• Mark a blocked item as blocked where it is. Moving it backwards breaks its timing and makes the work in progress look smaller than it is.
• To separate active time from waiting time, give each wait its own column, so entry and exit timestamps exist for both.

Statistics that look implausible are a signal to check the moving rules: if cards move long after the work did, the derived times are wrong. The fix is to correct the practice so that future data is right, keeping the record honest rather than editing or discarding inconvenient data.

Continuously sharing information means keeping the visual picture of work available at all times and giving each audience the view it needs, derived from the same live data the team maintains, instead of producing separate reports that drift from reality.

Walk the board at the daily meeting

A daily meeting that goes round the people centres on individual activity, and items close to done can wait while new work starts. Walking the board from right to left, starting with the column nearest Done, centres the meeting on finishing. The conversation at each card is about the item, not its owner's activity: what is stopping it progressing, and who can help today.

Different audiences, one source of data

Different people need different levels of detail, but every view should be generated from the team's live board rather than rebuilt by hand:

• Leaders and sponsors usually need an aggregated view, such as features or epics by state across teams, rolled up from the team boards.
• Governance bodies with their own formats can have their reports populated from board data, with a link back to the live board.
• External audiences can have a filtered, read-only view at the level they care about, which excludes internal or sensitive detail without creating a second board that someone must keep in step.

Hand-assembled reports and parallel trackers drift from the board, and then people argue about which figures are true.

Visualizing above one team

When several teams build one product, their dependencies need to be visible to all of them. A program board shows the features each team plans for the coming iterations, with the dependencies between them drawn as links, so anyone can see them at any time. At portfolio level, the typical problem is too many initiatives in progress at once, spread thinly across teams, so that little finishes. That is invisible on team boards, and it is fixed where initiatives are started: a portfolio board of initiatives with a limit on how many are active at once. Coordination structures such as scrum of scrums are covered in the lesson on a collaborative team environment.