Scaling Multi Team Scrum Delivery with Jira

Many organizations have multiple teams running Scrum and use Jira for work tracking and managing the sprint cycle.

Popular Agile scaling frameworks including Large Scale Scrum (LeSS), Scrum@Scale and Nexus all recommend having a single backlog and Product Owner.

This article will give you guidance on how to set up Jira and your teams to best support delivery of business value through having multiple teams working from the same backlog.

Setting up Jira to Support a Single Backlog

To set up Jira it is recommended that you have one Jira Project per product. This allows you to have a single backlog which can be ordered. 

Once you have an ordered backlog then you can create multiple sprints to represent the sprint backlog for each team. 

You can create as many sprints as need to support multiple teams or to organise the work, but remember the backlog should be shared so try to encourage collaboration and avoid teams assigning themselves items to far in advance.

Backlog with Multiple Sprints

If you are unable to create multiple sprints then Jira will have this disabled – see the gotchas below on how to enable it.

Each sprint can then be started independently with individuals or shared goals set in Jira. The start and end dates can be staggered. Often teams will start and stop sprints around the same time to allow for scaled events such as a cross team product review, retro of retros or pre planning (sprint planning 1).

Once running two active sprints the drop down below will allow you to select a single active sprint or display all of the sprint items on the board.

Active Sprint Drop Down

Gotchas

Jira Doesn’t Allow Multiple Sprints as Default

Running parallel sprint might need to be enabled (disabled as default). See the below screenshots of the settings that need to be configured. Settings -> Products -> Jira software configuration > parallel sprints

Settings menu – available for  Atlassian administrators
Jira Software Configuration Menu – parallel sprints option

Complete Sprint Button Disabled

One gotcha is that the  ‘complete sprint’ button will be disabled unless a specific sprint is selected. This has caught me out a few times, and I’m sure it will again.

This image has an empty alt attribute; its file name is Pg_H3KGL-d1l2zr8ubqidRWmbY5TfL-pg-b60CMfH8VXRecRXyGZydcIsBBd10Z28uwNKHmm7bhOdPFoCphGA-y18G7wQkM6FK0DF_gJFFS5FOqDox6AQk7YE7_izEG8uLhiNHP_
Complete Sprint Button Disabled Gotcha

Velocity Chart Does not Work for Multi Team Jira

The Velocity Chart report might no longer work as it is not designed to support selecting multiple teams. Thankfully the other reports will work and can be particularly useful.

I often use the version report to track the cross team burn up and monitor WIP with the cumulative flow diagram.

To review the past velocity you can easily navigate the sprint report to see the burn rate for each sprint.

Jira Reports

Teams / Organisation can find the Transition Hard

For teams already using Jira and multiple projects, you will need to move over issues from existing projects to consolidate, which can be a painful but worthwhile process. 

Just be mindful of the impact the change might have and be sure to consult the teams impacted.  It is better starting off with one backlog where possible. A benefit of starting fresh is an opportunity to ‘spring clean’ your backlog. Or do an Inception and multi team initial product backlog creation session.

Overall Jira works well for teams and organizations who wish to scale scrum to accelerate product development and reduce administrative and operational overheads.

Please reach out if you have any questions, need support with your Jira instance or require assistance with your scaling strategy.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s