Thoughts on the "best" structure in Jira to integrate Jira Align & Jira

[#1]

The Jira Align - Jira integration can support many approaches to the way work is structured in Jira. That is fantastic as the structure which is best for a specific organization depends massively on their specific situation. And as that situation might evolve so might the respective recommendation. However, if asked “what the best structure in a greenfield scenario is” - there is a clear preference. 

Details on the "program project" structure

• 1 project in Jira contains all the features/jira-epics and team-level work items like stories of 1 program
• a single-select "team"-custom field on team-level work items with its options representing the different teams in the program creates clarity over which team works on that work item 
• individual team-boards in the program project are based on the team-field and create a space for the team to collaborate 
• dive deeper in the community article Syncing the Team Field Between Jira Software and Jira Align 

What are the pros?

1) From a tooling perspective, this structure moves the program closest together.

All teams will be enabled to gain visibility of work from other teams and collaborate with each other most easily.

2) This structure contributes to minimizing the load on the Jira API.

The amount of integrated projects increases the load on the Jira API. With 1 project per program the amount of integrated projects will be minimized.

3) The user experience in Jira is best when using this structure.

When the data of a program lives in one Jira project, many Jira features work best (non-exhaustive list):

• the project or “basic” roadmap captures all the work in the program

• Features/Jira-Epics can be decomposed easier into Stories if Stories and other child-work items live in the same project

4) This structure scales well from a support & admin perspective.

The structure does not clutter Jira with projects as other structures might. As Jira reflects the teams and team-of-teams organizational structure, support & admins can connect issues with the data quicker. Permissions management in Jira becomes easier as well - in many enterprises access management is centralised via a webshop and for this structure, users would need to order access to one project to gain access to the entire program in Jira.

5) This structure is easy to understand for the users.
The project the user works in reflects the program the user works in. With one custom field, the data can be sliced so it generates views on the data of the team of the user.

And what are the downsides of this structure?

1) The ability to limit access to content within the program to certain members of the program is limited.

While this is not something we would recommend as it impedes collaboration across the program, sometimes restricting access to certain content in the program for certain users is a compliance necessity. An example could be a situation where multiple contractors are contributing work to the program objectives of a single program. Without further apps in Jira, only issue security would be able to fulfill respective requirements (please bear in mind that issue security is not available in Jira Align).

2) This structure prioritizes cross-program collaboration above team level autonomy.

If supporting team level autonomy is one of the top priorities for your Jira Align adoption journey, you might want to consider a Jira project for every team approach.

[Al Reid]

@Philipp Barry - This is a great article, thanks for posting!

[Dean MacNeil]

Thanks for this write-up Philipp! Glad to see a proven success pattern gaining acceptance. By the way, it works great at enterprises large and small that wish to organize around value and accelerate delivery supported by Jira and Advanced Roadmaps. At Valiantys, we have a service for this called “Level Up.” Then, when the time is right for Jira Align, there’s already a strong foundation to build upon.