Agile Banana

We recently started a sprint with user stories that were dependent on work being done by other scrum teams on a scaled agile project. The Problem The Tech Lead and Product Owner came to me with the initial assessment of the situation. The following nine items of work all needed to be coordinated, otherwise we'd face environment problems that would block progress on other tickets.  Specifically, Team Avocado and Team Bobcat needed to complete items in their sprint, before Teams Candyfloss, Dalmatian, and Elephant could complete items in their sprints. If teams Candyfloss, Dalmatian and Elephant didn't complete their work, then we'd be left with a situation where environments across the project would be broken and potentially inoperable.  Furthermore, an initial assessment by our Tech Lead determined that the items sitting with Avocado were "breaking changes" (represented by sticks of dynamite in the illustration above).  As soon as any one of these pieces of work w...

"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...