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
I would like to write a set of articles about delivery and release management in software development. In these articles, I want to share my experience of the delivery process organization and share a few cases of Release Management add-on / Release management for Jira Cloud usage. After years working within enterprises, my colleagues and I recognized a demand for such a tool. The first article in the series was about the optimization of microservices-based solution release management.
In this article, I would like to write about my observations on how the different enterprises structure their complex projects; visualize the drawbacks of such approaches and suggest a way on how to improve them with the help of release management apps.
It’s nosecret that Jira is extremely popular for software projects because of a superior user experience and flexible configuration. Jira could be easily configured to support all kinds of software development processes, but, according to my experience, there is one particular case where it does not work well. The case in question, is the tracking of complex multi-component deliverables created by several teams and consist of tasks from multiple Jira projects. The root cause is due to the fact that Jira doesn’t allow the creation of cross-project releases as each version entity belongs to a particular project.
In order to solve this problem, a great workaround was found: aggregate such a deliverable into an epic. Epics allow us to connect issues from multiple projects, visualize them on a single board and use all standard Agile reports. Actually, it sounds like a good solution, doesn’t it?
Based on my experience? No, not really.
The major disadvantages of this solution are:
I have aggregated all tasks under epic, and have started tracking its progress. Somewhere in the midst of the project the back-end team is progressing more quickly than was planned. The back office team is also progressing more quickly, but I have a huge delay for the Mobile native team which is working on the client-facing app, which is the ultimate goal for the entire project.
What will my epic report show? It will show that we are on track, as 2 of 3 teams are ahead of the schedule. Is the project really on track? In fact – no. So I would need to use some other reports to figure out our real progress.
Of course, I can create a few Agile boards with filters for each component/team and use them for each separate component tracking but it is not convenient to jump between the boards as a version report doesn’t have a dashboard gadget.
What is a better solution?
By design Jira versions should help to track each separate deliverable, so the solution of this problem could lie in the aggregation of multiple versions from multiple projects and the tracking of their progress separately, identifying a critical path on version level and spotting scope change for each version.
Let's map the case from the previous chapter to the release management app.
Displyed in the screenshot below is a release which consists of 3 versions. Each version has its own start-end date and number of delayed days, if any. Also, as an additional advantage, the user can define a workflow for a version and an entire release.
Even from this perspective, we can see that "Mobile native app V1" is delayed as this is causing the delay of the entire release.
Also, the release management app can visualize the release schedule on the timeline:
If you don't want to dive into the details - it will be enough to simply use the release status report or add it as a gadget to the Jira dashboard or import it to Confluence.
Furthermore, the user can spot any issues for the whole release, or for each version within the release:
As a result, we can have an aggregated view in order to see all items from all components to be done, in order to deliver functionality, but we don't lose the component view so as to be able to identify a potential problem in each particular component.
The app is process agnostic and can work with various software development methodologies: Agile, Scaled agile or classic Waterfall.
Release management can help to simplify the generation of release notes by aggregating multiple version content to a single report. I plan to write a separate article about practical use case studies of this feature adoption. Please tell me in the comments if this topic would be interesting for you.
I hope that this article will give useful insights to why epics are not the best solution for cross-project releases planning, and has shown you how our app can help to organize such a project in much more transparent and manageable way.
I would really appreciate if you can share your challenges with delivering complex projects in the comments and share your feedback about the article.
Thank you for reading.