Burnup Chart

For a long time, progress charts only drew the work that was left. You plot the total at the top and follow the line down day by day. That picture assumes the total stays fixed for the whole cycle, and in a real cycle the total moves almost every time.

So the second half of a sprint kept producing the same conversation. The line refuses to come down, the founder asks why it looks the same as last week, and engineering answers that two more items came in along the way. Those two items appear nowhere on the graph. One line can't separate a team moving slowly from a pile of work that grew, and without that separation the discussion turned into an argument about whose memory was right.

A burnup chart pulls those two apart by drawing a second line. The line rising from the bottom is how much the team has actually finished. The line running across the top is how much the team signed up to finish. When a schedule slips, you look at whether the bottom line flattened or the top line stepped up, and the cause falls out immediately. One is a question about the team's pace, the other is a question about whoever decides scope, and the two call for completely different responses.

A burnup chart is two axes, two lines, and an optional guide line.

1. Horizontal axis — time. Inside a sprint it's usually plotted by day; across a quarter it's plotted by week.
2. Vertical axis — amount of work. Many teams use story points, a number that describes the size of one item on a relative scale like 1, 2, 3, 5, 8. Teams that don't size in points simply count items.
3. Completed line — finished work accumulating. It starts at zero on day one and only ever goes up. Day 1 is 0, day 3 is 6, day 5 is 11, each point being the running total. Only work meeting the definition of done (DoD) counts here. The definition of done is a checklist the team agrees on in advance, usually something like reviewed, tested, and running in production.
4. Scope line — the total amount of work committed for this cycle. If nothing is added it's a flat line at 32; if a 5-point item arrives on day 3, the line steps up to 37 at that point. The shape of those steps is itself a record.
5. Guide line — a dotted line from the starting point to the scope on the final day. When the completed line sits below it, the current pace won't get everything done. Plenty of teams work without it.

The vertical gap between the two lines is the work remaining. When the completed line reaches the scope line, everything is done; if it hasn't reached it by the last day, that gap is what rolls into the next cycle. Reading the chart is mostly reading that gap over time: narrowing steadily means the plan holds, and staying the same width for a week means something needs a decision.

Usually nobody draws it. The work tracking tool already holds item states and point values, so the graph updates itself. The human job is keeping the picture honest. If people move items to done at different moments, the completed line runs ahead of or behind reality, and if new items never get entered into the tool, the scope line stays flat while the work grows.

Three groups read it, each carrying a different question.

1. The team — whether the current pace lands on the final day. Checking mid-cycle leaves room to decide what to drop; finding out on the last day is too late.
2. Stakeholders — when the promised thing arrives. Sales and marketing have to schedule their own work around a delivery date.
3. Leadership — the steps in the scope line. Frequent steps mean the list of work keeps changing after the cycle has started, which points at the prioritization process rather than at the team.

It also comes back out after the cycle, in the retrospective. A completed line that shoots up in the last two days means review and sign-off all happened at the end, which is something to fix next time.

"The burnup says the team isn't slow. Scope went up 20 percent."

Pointing at added work, not pace, as the reason the schedule slipped.

"Can you post this week's burnup? I want to see when the top line moved."

An intent to line up the moment scope grew with the decision that caused it.

"The two lines are running parallel. We're not finishing at this rate."

Work is being added as fast as it's completed, so the gap never closes.

Pagedeck uses this graph for quarterly planning. Mia sets the vertical total at the start of the quarter and plots the finished amount every Monday. In week 6 the gap between the lines was nearly identical to week 5 — not because the team stopped working, but because three new items arrived from an enterprise customer. With the step in the scope line visible to everyone, the meeting shifted from "why are we late" to "do these three belong in this quarter."

Grace looks at the same picture with a different focus. If the scope line stepped up four times across the quarter and three of those came from the same customer, the thing to fix isn't the team's pace but the step ahead of sprint planning where work gets selected.

The most common mistake is reading every step in the scope line as a failure. Steps look like scope creep, work quietly expanding without anyone agreeing to it. But work growing because the team learned something is normal. If a missing screen turns up during build, or customers turn out to use the product differently than assumed, scope should grow. Treat steps as a sin and the team starts handling new work quietly without entering it, which flattens the chart while the schedule slips exactly as much as before. The question isn't whether steps exist but whether each one has a record of who decided what, and on what basis.

The second mistake is using the graph to measure pace. A steep completed line looks like a team speeding up, but the slope follows the mix of item sizes in that cycle. A cycle full of small items climbs steadily from the start; a cycle with a few large items stays flat for a while and then jumps near the end. Two cycles with identical amounts of work can produce completely different pictures. To compare pace, look at velocity, which averages whole-cycle totals.