Why epic is not the best solution for tracking of cross-project releases

[#1]

Introduction

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.

Problem statement

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:

• Epics don’t have  start and end dates, so it is very difficult to build a timeline using standard tools. Of course, Epics reports can calculate the expected delivery date but statistics haveto be collected to make such  predictions. Also, there are no epic burn up gadgets out-of-the-box.

• In cases where the epics are used for tracking cross-project deliverables, the teams can’t use them for classical purposes as each user story can belong to one epic only.
• There is no automated report to track scope change for a particular  period of time.
• Version burndown report works incorrectly in the case when the epic scope is done in multiple parallel sprints
• From my point of view, the biggest problem is that all epic reports calculate cumulative progress and do not allow us to track progress for parallel multi-component development and identify what component is on the critical path. For example: In order to deliver a business feature - following versions to be delivered:
  • "Mobile native app V1" from MA project,
  • "Back office V1" version from BO project,
  • "Back end services V1" from BE project.

Initial plan

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.

Release management app (or Cloud version )solves such a problem. The user can create a cross-project release which can consist of a few versions from various projects.

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.

Extra features

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.

Conclusion

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.