You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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