Using SpiraPlan for Program Backlog Planning with Jira and A

January 4th, 2024 by inflectra

We have had several prospective customers ask us how they can use the new program planning and backlog management features of SpiraPlan to help them do program backlog planning and portfolio management of multiple project teams even when the individual teams are using a combination of other tools such Atlassian Jira and Microsoft Azure DevOps. The SpiraPlan data-synchronization infrastructure, in conjunction with our program planning functionality, comes to the rescue.

using-spiraplan-for-program-backlog-planning-with-jira-and-azure-devops-image

Background

We have had several clients come to us with an interesting problem:

They have multiple agile project teams that are using different project management and agile planning tools such as Jira or Azure DevOps (ADO). For example, their .NET projects use ADO with Azure, and their Java projects use Jira and Amazon Web Services (AWS).
Each of the teams is able to plan their own backlog in Jira/ADO, but the higher-level Program Management Office (PMO) had no way of understanding how the different teams were working towards the higher-level program capabilities and value streams. The PMO was looking to adopt a Scaled Agile methodology such as SAFe, and liked the functionality in SpiraPlan for managing program backlogs but could not change the tools used by the teams.

The solution was to use the Spira data synchronization service in conjunction with our plugins for Jira and ADO and the Scaled Agile functionality of SpiraPlan. Problem Solved!

The Solution

Using SpiraPlan Program Capabilities

Using the Scaled Agile program management functionality in SpiraPlan, you can easily create capabilities that describe the high-level business value that a new aspect of the program will bring. These capabilities can be classed into Epics and Features as shown below:

In SAFe terminology, these are the program backlog items that consist of both business features and potential technology enablers. They will span multiple projects and teams. In this example, we have created a new program capability called "Generate cross-system reporting functionality". This new capability is shown to have a 50% completion state. We shall show you where this comes from later in the article!

You can then map these program capabilities to program milestones. These milestones are the high-level dates and goals by which one or more capabilities should be done by. For example, our new capability could be included in the "Major Q1 Release" milestone due at the end of the first quarter.

Mapping to Product-Level Backlog Items

If you now drill down on the specific capability, you can see the different product backlog items (requirements) that the capabilities map to. In this example, the new program capability requires three Jira user stories and one ADO backlog item to be completed for the capability to be marked as fully complete.

The great news is that each of these items is directly linked to a corresponding item in Jira:

Similarly for the user story backlog item in ADO, the SpiraPlan requirement maps to it automatically:

So, as the teams work in Jira and ADO to complete the various product backlog items, the overall capability status in SpiraPlan will be updated accordingly. The PMO can then plan the overall program in SpiraPlan, defining the capabilities and milestones, then leave it up to the product teams (working in Jira/ADO) to keep their status up to date. They can then get a top-down view on the progress of the capabilities. In this example, once all of the Jira/ADO backlog items are marked as completed, the progress bar of the capability in SpiraPlan will show as 100% green.

Reporting Across the Program

We recommend grouping the various SpiraPlan products under the overarching SpiraPlan program. This lets you have the individual teams work separately and still facilitate the PMO to have high-level visibility. We believe this gives the teams tactical autonomy yet affords the PMO a strategic view of the projects. The benefit of this approach is that it avoids the temptation of micromanagement that could happen if the PMO tried to dictate the product-level backlog directly (and is an agile anti-pattern).

Within SpiraPlan you can view the products in the program and use the project portfolio management functionality to tag the different products and report on them accordingly:

The program dashboards include several different reporting widgets to allow the PMO to see the status of the program. There is a capability view that lets you see the overall progress of the different program capabilities by milestone:

In addition, you can drill down further to display the product-level information to see the progress of the product backlog items in the active releases/sprints:

This includes all of the active products in the current program.

Conclusion

When you use the SpiraPlan Scaled Agile program backlog management functionality in conjunction with the Spira data-synchronization platform, you get the best of both worlds (the "genius of the AND"). You can plan, track, and manage complex programs consisting of different heterogeneous teams and yet give those teams the flexibility to use other tools, such as Jira and/or ADO, to manage their own backlogs.