Soft development - single vs multi projects

Hi folks,

A question for all you JIRA gurus.  As we're moving further and further into modular projects, each having their own release life-cycle, we're trying to come up with the best/easiest way of dealing with them. I don't consider this a unique problem that we have. I'd say pretty much each software company will end up with issue like this and still I see no obvious solution.


Basically we have a layer of back-end services (modules) that are serving different products (front-ends). Example front-ends are iOS & Android native app, web app etc.. Sometimes those front-ends need to be in sync but most of the time they can have different release cycles.

Our current approach is to use multiple projects for each module:








This has the advantage that each module is its own project, with its own project lead, settings, and release life-cycle which better reflects the module.

The disadvantage is that this breaks the use of sub-tasks. Currently to reflect a single task that propagates into more than one module(projects) and actually complete a "Story" we end up crating Epics as JIRA natively does not support sub-tasks in multiple projects. Ultimately we end up with hundred of Epics for even smaller tasks.


An alternative would be to use a single JIRA project, and having multiple open versions for each module, such as:


    Module A 1.6.0

    Module B 1.3.0

    Distribution Release 3.0.0-GA


    Module A 1.6.1

    Module B 1.3.1

    Distribution Release 3.0.1-GA


This has the advantage that a single issue can be configured with a FIX-FOR for multiple versions to indicate the fix affects multiple sub-modules (components). Here I can see some overhead on tracking if correct versions are applied and setting like 5-6 versions (5-6 modules) per Story.


I was wondering if there is a general consensus from you guys over which way is better, or worse, or preferred?


Some of the side-issues that we're looking at is also reporting on the progress of a project, or iteration - for example, iteration N contains work on Module A 1.6.1, Module B 1.3.1, and Module C 2.0.4.  Being able to have a nice roadmap that covers a set of versions would be great (and would work with either the single, or multi-project setups)

Look forward to hearing from you smile



1 answer


for plannings and rollout purposes of greater scopes, you might find Jira-Portfolio useful, there is a new level above the Epics spanning over several projects called initiative. You could manage initiatives, epics, projects and teams and decide how to get them in synch. This is helpful if you want to open the scope above the epic-level.

Another thing that might be helpful is the usage of Epics as project spanning projects/orders/rollouts. The summary of what is inside the epic for reporting could be done by Epic SumUp. This is helpful, if you want to use PM Features "below" the Epic

Hope that helps..



Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 29, 2018 in Jira

How to set up an incident workflow from the VP of Engineering at Sentry

Hey Atlassian community, I help lead engineering at Sentry, an open-source error-tracking and monitoring tool that integrates with Jira. We started using Jira Software Cloud internally last year, a...

1,097 views 0 8
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you