Which is best? Multiple projects with 1 release or 1 project with multiple releases?

Craig Baillie September 13, 2019

So I'm a Jira admin, helping advise different departments on their Jira implementation. In keeping with Agile principles I'm happy for teams to organically find workflows that work for them and customise accordingly. Recently, one team got started with Jira and opened up an interesting discussion.

Is it better to create separate projects for each release, or separate releases within each project?

My gut feeling is to just set the fix version for each release, and create a 'release' when finished but the team wanted to go for separate projects for each release, stating the following reasons...

  • They don't want to see any of the issues from previous releases - Those issues are either moved to the next project, or to a separate project of 'live issues'
  • When using the quick search links 'open issues' etc, it would otherwise include things not in scope for the release.

Thoughts?

2 answers

5 votes
Ravi Sagar _Sparxsys_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 13, 2019

@Craig Baillie 

Definitely in this case 1 project with multiple releases makes sense. This why fix versions are there in Jira.

I think it is more of a case of training the users about filters, issue navigator, dashboards and reports. Since you mentioned agile. Also educating them on using epics, labels, boards with relevant issues only and utilising these capabilities to the fullest of Jira.

Ravi

0 votes
Ste
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 15, 2019

I concur with @Ravi Sagar _Sparxsys_

It's important users learn how Jira works - it is a flexible system and teams should use it to suit their ways of working. But, there can be pitfalls to some approaches.

In the instance you've described, I think it makes sense to have one project assuming this is one product to be delivered or one team delivering consistently. This is because:

  • One project ensures the releases are all in one location - to allow for release-based reporting and...
  • It reduces administration - otherwise you're managing a unique set of components, users, releases, etc per project created
  • All the issues sit under one issue key - which I think is important to show parallel work being delivered

The concerns they've mentioned can be handled through some knowledge of the boards and issue filters - for example:

  • Boards have a version tab - they could filter to only show the release they're working on or...
  • They could add a quick filter to not show issues from previous releases
  • For 'open issues' - they could build custom filters they can save as favourites to manage for their scenario.
  • In turn, they could add these to a 'team dashboard' to visualise what they have coming up in the next release

^ Easily manageable and less convoluted than having multiple projects.

Ste

Suggest an answer

Log in or Sign up to answer