Jira Align and Jira Integration Best Practices and FAQs: Teams and Sprints

[#1]

Jira does not natively have the concept of a “Team”. The closest object in Jira that mimics a team is a rapid board in Jira Agile. Whether a team is using Scrum or Lean/Kanban, Agile best practices call for that team to have their own, single, backlog and tracking board, so that the team is able to focus on their own work and track individual team metrics, such as Velocity or Cycle Time.

Given these conventions, Jira Align considers a rapid board in Jira to equal an agile team, and the Jira Align/Jira integration will create one team in Jira Align per board that is configured.

Best practice: One rapid board = one agile team

Create one rapid board per team, whether a Scrum or Kanban board. Have each team work solely on the one team board. Use Jira Align to obtain roll up views and metrics. See the FAQs for more information on specific cases.

Best practice: Issues should show up on one rapid board only

Issues (stories, bugs, etc.) in Jira should only show up on one Team rapid board at a time. This is accomplished via the board filter. You may still have other boards in Jira that you have used in the past for roll-up views that show the same issues – these will not be integrated. See the FAQs for more information.

Best practice: One active sprint per rapid board

Have one sprint active at a time for Scrum Boards. It is fine to have future sprints not activated that are used for future planning. Multiple concurrent sprints are not part of Scrum methodology and are not supported in the integration. See the FAQs for more information.

FAQs

Q: What if I have multiple teams using the same rapid board?

A: It is usual for team leads who are responsible for many teams to set up a single rapid board and have all their teams use that one board. Typically, this is done so the lead can look across all teams at once. Doing this, however, confuses the internal Jira metrics, as the teams cannot track their own Velocity or Cycle Time or identify their own backlog ahead of sprint planning without bending Jira constructs to different purposes than intended. As Jira Align is inherently a platform intended to help leaders of all kinds aggregate data and metrics across multiple teams, using such a setup in Jira becomes unnecessary for the team lead once Jira Align is deployed and integrated to Jira.

If you want to continue using one rapid board for multiple teams, and you adhere to a naming convention for your sprints that includes the team name, then separate boards can be set up just for the integration to use that filter on the name of the team in each sprint. For instance, if you have “Zeus Sprint 1” and “Athena Sprint 1” on the same board, create a board called “Zeus Integration Board”, and have the filter for the board use “sprint = Zeus” as part of the filter – do the same for the Athena board. This will be the board Jira Align is integrated to and the team members need not change the way they work or even know about the existence of the board.

If you do not use the convention above, then that multi-team rapid board will become just one team in Jira Align. As in Jira, you will not be able to track individual team metrics like Velocity, and will only get an aggregate metric for the entire group of teams. The bigger issue comes into play if you use multiple active, concurrent sprints on the same rapid board. Jira Align does not allow sprints for a single team to overlap, as that would be a bad Scrum practice and violate the purpose of sprinting. The work around would be to map all the active sprints from Jira to just one sprint in Jira Align. This would require manual intervention every time new sprints are activated and is not ideal. To change sprint mappings, go to Team > Manage > Sprints, and then select the Manage Jira Sprints option from the More Actions menu at the top-right of the page.

Q: What happens if I have teams using multiple boards for different types of work in Jira?

A: Sometimes product owners or other stakeholders prefer to keep “their” backlog and active work on their own board, and teams have to jump from board to board to do work in the different work streams. This is against agile team best practices, as there is no one view of all work for that team.

If you continue to use multiple boards for one team, each board will become its own team in Jira Align. You will not be able to get consolidated metrics for any individual team that is working across multiple boards. Each of these teams created will get their own set of sprints which will map to the sprints on each of those boards. In Jira, however, it is possible to physically share the same sprint object across multiple boards. If this is what you do, then all work in that sprint will show up in just one of the sprints for one of the teams that got created in Jira Align, further throwing off metrics and confusing object mapping.

Q: What happens if I have my team boards set up so that a single issue (story, bug, etc.) can show up on more than one board?

A: Typically, in Jira you assign issues to a team via a custom field (“Team”, for example) or you have each team's work within their own Jira project, so they own all issues in that project. When an issue is first created, it may not yet be assigned to a team, so the “Team” field would be left empty or the issue would have some other identifier that can be filtered on to indicate it is not assigned to a team yet. If these conventions are not used, and an issue shows up on more than one team board, then the Jira/Jira Align integration cannot determine which team owns that issue and the team will remain unassigned. Once that issue is assigned to a sprint, Jira Align will assign it to the team that owns that sprint. Should the issue be assigned to multiple different team sprints at the same time, the integration has no choice but to pick just one sprint, as a story in Jira Align naturally belongs to just one sprint at a time. Jira Align will pick the sprint with the latest dates in this case.

Q: I have created my own “roll-up” boards in Jira to try and see cross-team progress or else to perform backlog grooming. What do I do with these boards?

A: “Roll-up” or backlog grooming boards should not be integrated. They do not represent a single agile team and will cause many of the difficulties mentioned above. You can keep your roll-up boards in Jira, but you will also find that Jira Align provides the type of roll-up views and backlog grooming facilities being mimicked by these boards.

Q: Some boards use future sprints as buckets for categorizing work. Examples: A sprint named “To Delete” or a sprint named “Grooming”. What happens to these “fake” sprints?

A: As these are sprint objects just like any other in Jira, the integration will create these as sprints within Jira Align, likely with unusual dates as the bucket sprints tend to be older than the current sprint. Do not create “fake” sprints in Jira. Instead, use labels or custom fields to filter for issues that you categorize in this manner.

Q: I have a team that uses one board, but we have two sprints running at the same time (concurrent dates) to indicate different work streams. What will happen in the integration?

A: You would have to manually map both sprints to the same single Jira Align sprint every sprint cycle. This is the same issue as mentioned in What if I have multiple teams using the same rapid board? It is best to have ONE active sprint per board. Use labels or custom fields to filter the issues for the Jira views.

[Shawn Kessler]

@Tim Keyes Very informative article! This should save Jira Align customers lots of time, seeing all these answers in one place!

[Tim Keyes]

Thank you @Shawn Kessler 

This was definitely a group effort from Slava, Olena, Tina, Emily, you and the SA team!

[Connie Crabbe]

Do you have any information on getting teams currently working in Jira Align migrated over to Jira via the connector?

I've found there are a lot of issues going backward and wanted to find out if you have this scenario documented anywhere.

For example, sprints need to be in place, Features need to sync over before Stories etc.

[Tim Keyes]

Hi @Connie Crabbe

Thank you for reaching out!  I hope all is well.  We do not have any public facing content in this space as most of our customers have implemented Jira Align in conjunction with Jira or Azure Dev Ops.

If you consolidate a list of comments/ questions with your Atlassian TAM we are happy to look into them!

Thank you.
Tim