Before integrating Jira with Jira Align, there are some best practices that should be considered. Some are a little more rigid than others; while others can lend themselves to some workarounds. Let's explore further to understand what these are, why these are important and the potential impacts.
All teams must have the same length sprints (1-week, 2-weeks, 3-weeks) within a program and must be consecutive.
Why: Anchor sprints (which team sprints roll up to) are generated by PI. Anchor sprints are used at the Program level for roll up of team data and sprints. This is needed to effectively plan and manage work across teams.
Sprints cannot be shared by multiple boards. Sprints also cannot be moved from one board to another.*
*For example, team decides to create a new board and retire their previous board and shares sprints to new board. Another example, team splits into two teams and sprints shared to new board.
Why: In Jira Align, it is only possible for sprints to belong to one team. The connector will associate sprints with the board from where the sprints were created. Team-level issues will sync over but will not be properly assigned to teams. Errors will be generated in the logs. In addition to cleaning up sprints, issues will need to be corrected as well.
Workaround: In the case where a team created a new board and using sprints from their old board, there is a setting (Sprints created and shared to board) that can be temporarily enabled to allow bringing in these sprints. The team must create sprints from the new board going forward.
Does not apply: Next Gen projects do not have the ability to have multiple boards per project.
Some teams will use “holding” or “bucket” sprints for stories that have been groomed and are ready for a sprint. This is not supported in Jira Align and this type of sprint must be ignored (if used).
Why: The connector cannot differentiate between true sprints and fake sprints. Therefore, it will build these fake sprints into the team sprints in Jira Align creating misalignment of sprints. Corrective action needs to be taken when this happens.
Workaround: If a fake sprint is used, it must be ignored in the connector. Reuse the same one PI over PI and just rename it if needed. If new ones are created, they will need to be ignored in the connector. If creating new ones, Admin will need to be informed to ignore sprint in connector.
General Best Practice (not specific to integration): Sprints should represent work to be done within a certain time box. Use statuses instead of bucket sprints to represent groomed stories.
Product Managers should not be placing holding work for teams as this does not foster agile practices.
Does not apply: Not an issue for Data Center.
Set sprint dates ahead of time with unique start and end dates. If using the Start Sprint option to generate dates, make sure the start date is the the first date of the sprint when starting the sprint.
Why: Jira Align doesn’t recognize time stamps that can be set/generated in Jira; only the dates. Overlapping of start and end dates could result in inaccurate mapping.
When using the the Start Sprint option to generate dates on sprints, the start date defaults to “today’s” date. If the sprint is started for some reason after the first date of the sprint, this needs to be adjusted. When selecting “weeks” options as the Duration, it will cause the last date of the current sprint to overlap with the first date of the next sprint. The custom option allows for appropriate setting of the end date.
There should only be one active sprint at a time per board. Future planning sprints are acceptable. There is a setting in Jira that can prevent having two active sprints.
Why: The connector uses the active sprint in Jira to build future sprints in Jira Align. If there are multiple active sprints, the sprints may become out of sync in Jira Align and corrective action will need to be taken.
General Best Practice (not specific to integration): Team velocity can become inaccurate when multiple sprints are active at the same time.
Sprints should be created and managed in Jira. Management includes any changes such as the name, starting and completing sprints.
Why: Sprints sync unidirectionally from Jira to Jira Align. Sprints created in Jira Align will not sync to Jira. Sprints started or completed in Jira Align will not sync to Jira. Updates made to sprint names in Jira Align will not sync to Jira.
If there is a desire to create team IP sprints in Jira Align, these are not treated any differently in reporting in Jira Align and there would be no value in this action.
Once sprints have been created on the Jira board and synced to Jira Align, they need to remain in the order they were created.
Why: If sprints are rearranged (dragged and dropped after sprints have been synced) or deleted, it can cause the sprints to be out of sync b/w Jira and Jira Align. If this is done, manual corrective action will need to be taken.
It’s better to rename sprints than to delete or move.
Cannot use parallel sprints to divide work between regression and enhancement work sprints. (Other examples are division of QA and dev and delay with PO accepting stories.)
Why: If selected, it is not possible for the connector to determine which one to sync because it will generate two active sprints. When the second sprint closes, it will create a syncing issue.
Setting is not project specific and is whole instance.
Related article: Cloud: Use parallel sprints
Rae GibbsAtlassian Team
The roadmap challenge for large scale agile enterprises Regardless of the agile framework you use, the agile enterprise has a massive scale with the challenge to connect hundreds of teams and thous...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events