Finally, we made it to the final article!
Previously, we already told you about how to organise releases with the Release Center and how releases from various sources get into it. And today we are discussing ways to make our desperate Release manager the happiest person in the world by visualising all releases and collecting the necessary metrics and KPIs.
Without further ado, let’s get into it!
Let's start with the most important aspect of an effective visualisation: a bird’s-eye view of all releases. As you remember, releases are stored in a separate Release Center as epics, and the most convenient way to display them is using Jira Software roadmaps:
Let me remind you that each epic in roadmaps is a release. In turn, the release is tied to the application, and each release has (but is not limited to):
Note, since this is a separate project in Jira, you can add your custom fields and populate them with the values manually or automatically from other projects, releases, changes, etc.
Using the Release Center as a single source of truth of all releases and the place for our release manager to chill, you can collect the following release-related metrics and KPIs.
If you are using JSM Premium, you can connect Services from Assets as Applications, and receive reports based on this information.
Otherwise, you can use components or custom fields for Applications, and create reports based on those fields.
To make sure you don’t have a conflict and are not planning everything to be released on the same day (we do love chaos but not to this degree 🙂), if you are following proper change management and use JSM changes, you can use change calendar available in JSM Premium.
Alternatively, you can use calendars connected to the release dates for your reporting.
Or just use Jira Software roadmaps, as it already shows you all the important dates. Roadmaps are also useful to visualise the release duration, so you can measure how quickly you can provide the released functionality to users.
Each release has a certain workflow and can be marked as successful or rolled back.
You can report on workflow statuses per application, or for all releases in total.
The above reports should be especially useful also to provide you with the number of release backouts so that you can investigate such cases in more detail.
Deployment duration is useful for understanding whether deployments are causing delays. With the integrations with the development tools, we can get the deployment information right in Jira and use it for reporting purposes.
This number is often used as a key metric in evaluating team performance. Releases in the Release Center are connected to the real releases from the software development projects, in which you have linked all the features, user stories, and bugs as well. So we can take the number of bugs connected to the same version, and use this for further reporting. A simple Jira search by the fixVersion or Jira filters will be beneficial in this case.
This metric refers to the average duration of the release. Since you are using the Jira Software project as the Release Center, you can use Kanban reports here (to track the duration of our epics).
A control chart, for example, can assist you with the average duration of the release.
Also, there are additional reports tracking average time, for example, which you can also use.
Finally, you may want to connect Power BI or any other reporting tools to pull your release data from Jira and perform advanced reporting.
These are just a few examples of visualising releases and leveraging powerful Jira reporting capabilities. Using them, you can report and analyse everything happening in the Release Center.
What else may be needed to make our already content and relaxed release manager even happier? Please let us know below.
Nadia
Senior Project Manager
Itransition Group Limited
London, United Kingdom
1 accepted answer
1 comment