Skip to main content

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.