Cross-team burnup charts: how to track several teams without ranking them

Three teams are working on the same initiative. Someone in a steering meeting asks for one chart that shows how it is going, and somebody else, usually a little later, asks for the version that shows which team is behind. The first request is reasonable. The second one is where most cross-team burnup charts start lying.

A cross-team burnup chart plots how much of a shared piece of work several teams have finished, against how much of it is in scope, sprint by sprint. It answers "are we going to land this, and is the scope still moving?" Built carefully, it is one of the most honest pictures a multi-team effort can have. Built the obvious way, by adding every team's story points into one line, it measures how generously each team estimates and calls the result progress.

What is a cross-team burnup chart?

It is an ordinary burnup with more than one source. There is a scope line, which is everything currently planned into the initiative, and a done line, which is everything finished. The gap between them is what is left. If the scope line keeps climbing, the finish date is moving no matter how fast the done line rises, and that is usually the most useful thing the chart says.

If you have not read a single-team version closely, the worked epic and initiative burnup example goes through one sprint by sprint, and burn-up versus burndown covers why the burnup is the one to trust when scope changes. Everything in those posts still holds. The cross-team version adds exactly one problem: units.

Why you cannot add story points across teams

Story points are relative. Each team calibrates them against its own past stories, which is the whole point of relative sizing, and it means a team's 5 is only comparable to that same team's other 5s. Two teams can look at the same piece of work and call it a 3 and an 8, and both can be right for themselves.

So here is what happens when you sum them. Team A sizes small and finishes 20 points a sprint. Team B sizes large and finishes 60. On a combined chart, Team B's work dominates the done line, and the initiative seems to move when B moves and stall when B has a quiet sprint, even if A just closed the hardest part of the whole thing. Nobody looking at the chart can tell that, because the chart has no way to show it.

It gets worse once the chart has an audience. Tell teams their points are going onto a shared chart in front of leadership and, within a couple of sprints, every estimate drifts upward. Nobody decides to inflate anything. It just happens to every number that becomes a target.

Scaled frameworks know this, which is why SAFe has a whole section on creating an estimation baseline across teams. Shared points can work if you are prepared to pay for them: a common reference story, regular joint estimation, and recalibration whenever a team drifts. What does not work is the cheap version, one joint refinement session and then hoping. Each team plans its own sprints in its own scale, every sprint, so its own scale is the one that wins.

The two versions that work

You do not need shared points to get a truthful chart. You need a unit that means the same thing on every team, and there are two.

The first is a combined chart in story counts. Instead of summing points, count stories: how many are in scope across all teams, and how many are done. A story is not a fixed amount of work either, but teams that slice stories small, which is good practice anyway, end up with stories of roughly similar size. Counting them is cruder than points and much harder to game, and it is the version to show a steering group that wants one line.

The second is side-by-side percentages. Each team gets its own done line, drawn as a share of its own scope, all on one axis that runs from 0 to 100 percent. You can use points here, because every team is only ever divided by its own numbers. This is the version that answers "where is the risk?" without pretending to answer "who is better?"

Here is a small example, four sprints into an initiative shared by three teams:

Summed, that is 107 of 200 points done, 54 percent, and Mobile carries most of it simply because it uses bigger numbers. The percentages tell a different and more useful story. Payments is nearly there. Mobile is halfway, with stable scope, which is fine. Platform is the one to talk about, not because it is slow, but because its scope has nearly doubled since the start: it began with 16 points and now has 30. That is the conversation the meeting should have, and the summed line would have hidden it completely.

How to build one in a spreadsheet this sprint

Many tools will not draw this for you, and you do not need them to. A spreadsheet and ten minutes at the end of each sprint is enough.

1. Agree what belongs to the initiative. In practice that means a set of epics on each team's board, or a label. Write the list down, because "is this story part of it?" is the argument you want to have once, not every sprint.
2. At the end of each sprint, take a snapshot of each team's stories in that set: how many there are, how many are done, and their points.
3. Add one row per team per sprint to a sheet with the columns sprint, team, stories in scope, stories done, points in scope, points done.
4. Chart the summed story counts for the combined view, and done points divided by scope points per team for the side-by-side view.

The snapshot has to happen at the same moment every sprint, ideally right as each sprint ends. Taking it a week late does not give you a slightly worse chart. It gives you points that each cover a different stretch of time, and once people notice that, they stop trusting the line.

What the big tools do

It is worth knowing where the tools stand before you build anything by hand.

Jira's built-in burnup report tracks one team's progress through a sprint. When people need a chart across several teams in Jira, it usually comes from one of the reporting apps on the Atlassian Marketplace, and those are worth a look if your organisation is already deep in Jira.

Azure DevOps does this better than most. Its dashboard burnup widget lets you add more than one team to the same chart, and you can choose to plot by a count of work items or by summing a field like story points. If you use it, pick count, for every reason above.

Scrumpy does not draw a cross-team chart, and I would rather say that plainly than dress it up. Epics in Scrumpy belong to a single team, and there is no initiative layer above them; that is portfolio territory, and Scrumpy is built for a team that wants its own board to be quick and readable. What it does give you is the raw material for the spreadsheet above. An organisation admin can download the data export from the import and export settings. It is an Excel file with one sheet per team, and each sheet lists every story with its epic, sprint, status and story points. Filter each sheet to the initiative's epics, skip the rows marked as deleted, count, paste one row per team, and you have your snapshot.

How not to read it

The percentages view will tempt someone to rank the teams. Resist it out loud, ideally before the first time the chart is shown. A team at 30 percent might be doing the hardest, least predictable part of the work. It might have been handed scope by everyone else. It might simply have started later. The chart cannot tell you which, and it was never meant to.

What it can tell you is where to ask a question. A flat done line usually means something is blocked. A climbing scope line means something is being discovered or being added, and somebody should decide which. A team whose line is both flat and climbing is the one to visit first, with curiosity rather than a deadline.

If your teams are small enough that one shared board would do, it might be simpler to skip the cross-team chart entirely and run them on one board with one backlog. And if they are separate teams, give each one a board it actually likes using. Scrumpy is free to try for seven days, and a team whose board is up to date is the only kind that produces a snapshot worth charting.