How do we know if we're on target for a release across multiple scrum teams?

"We need a burn-up chart so we can see if we're on track."

This was a request that came from programme management, and needed a bit of unpeeling. 

What are we trying to achieve with the burn-up chart? What is the problem that we're trying to solve?

After talking through a few examples of burndown charts, and the reporting features in Jira - we decided that ultimately, the question we were trying to answer was this: "are we on-track to finish the product in time for its scheduled launch date?"

So -- what do we need to answer this question? 

The first thing that sprang to mind was a list of the must have requirements for the first product release. Without this, we wouldn't know what we were monitoring our progress against.

Although we had a list a epics that we knew were needed for the release, these were very (VERY) high level. If they had been estimated, I wasn't aware of it.

But then the uncertainty in my mind was how to track against the must haves, when the release was over a year away. Asking the programme to produce a list of user stories up front seemed to go against the 'just in time' approach that avoids sunk costs in agile.

Or perhaps not - maybe you could identify high-level user stories under each epic without delving too much into the details. Attaching some conservative estimates, we could then use sprint velocity to plot on a graph to see whether we're going to hit the release date. 

Alternatively, when we got to the stage of decomposing an epic, we could ask what the must have's are for the product release. Then, choose an appropriate milestone, and track progress against the must have's across several epics on a release burn-up.

We currently track progress across multiple scrum teams by looking at the product roadmap. The limitation here is that it doesn't show if we're speeding up, or slowing down. Only if we're on track or not, and the extent to which we are on track or not.