Soft development - single vs multi projects

[Julian Davchev]

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:

  PROJA-MODULEA-124

    Released

      1.6.0

    Unreleased

      1.6.1

  PROJA-MODULEB-123

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:

  Released

    Module A 1.6.0

    Module B 1.3.0

    Distribution Release 3.0.0-GA

  Unreleased

    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

Regards,

JD

[Andreas Haaken _APTIS_]

Hi, 

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.

https://marketplace.atlassian.com/plugins/com.radiantminds.roadmaps-jira

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 

https://marketplace.atlassian.com/plugins/aptis.plugins.epicSumUp

Hope that helps..

cheers

Andreas