How to manage the Nexus Sprint in JIRA

Last post 11:21 pm February 5, 2022
by Thomas Owens
2 replies
02:02 pm February 4, 2022

Hello All,

We use Nexus to scale 8 SCRUM teams, all working on the same backlog. We use JIRA and one Project to manage our backlog. I wanted to get recommendations on how to manage the “Nexus Sprint.”

I want to take full advantage of the following reports:

-        Velocity report based on the Nexus Sprint

-        Sprint report based on Nexus Sprints

-        Release Burndown by Nexus Sprints

One approach we are considering is having one Sprint shared across all teams. That Sprint will be officially the Nexus Sprint, and each Team will have their own aboard filtered by their Team ID (custom field). We are worried that starting/stopping the Nexus Sprint will be a challenge across multiple teams and regions.

Another approach is that each Team manages their own Sprints, and the Nexus Sprint is a filter (of all active sprints). However, the release burndown and Velocity reports are exploded by team sprints. Therefore, the charts are mainly by Team but do not show stats on the Nexus Sprint itself.

We know we can collect the data in external tools, but we would like to use internal JIRA charts as much as possible. We also have other tools such as Portfolio for JIRA, EasyBI, and ScriptRunner. Any ideas on how to get the most visibility out of the Nexus sprint will be appreciated.

06:53 pm February 5, 2022

Any ideas on how to get the most visibility out of the Nexus sprint will be appreciated.

You need transparency over any challenges presented to integration. That's it. Self-managing teams within a Nexus ought to do the work.

If something else needs to be monitored I'd wonder if there's a gap those teams aren't covering. A "release burndown" always smells fishy.

11:21 pm February 5, 2022

I would strongly advise against looking at velocity and other metrics across the whole Nexus. Is there a reason why the teams can't choose what data to use in order to support their Sprint Planning?

Using Jira, I would recommend that all of the work go into a single project and use a custom field, like you are doing, to identify the team associated with the work. But beyond that, I'd let each team operate as an independent team within the framework. That means they would have their own board, their own metrics, and their own Sprints.