Best Practices for Setting Up a Project

Hi All - I've never used JIRA but my manager has asked me to set up a project in the free trial and I'm wondering about best practices. The project that has been given to me is for a Web Portal and is broken up into 3 main parts all with 10-20 tasks in each part. My question as of right now is do I set this up as

A) 3 different projects


B) 1 project with 3 parts and sub-tasks under each of the 3 parts in the project?

Or, is there a better way all together?

Any info you have would be greatly appreciated! Thanks!

1 answer

0 votes

There are several ways people might split a project into many jira-projects - along team lines, process lines, business units, and so on, but the main consideration is "what are the issues going to have in common?"

A good one to look at is the release cycle.  If you have one end product (your Web portal) and it has a distinct release cycle (e.g. it's on version 1.2 now, and you're probably going to release 1.3, 1.4, 2.0, 2.1 etc), then it's a good candidate for a single project because JIRA's version field is handled at a project level.  If it's made up of several modules that bolt together and have different release cycles, then you probably want a project per module to handle that. 

Re-reading the question, I think you've got two approaches, which you have already stated, and it's dependent on how I would translate from what you have written into "JIRA speak", and I'd recommend basing it on your release plans.  So

A) Three projects, one for each "part".  10-20 issues in each project, separate release cycles

B) One project, with three "Components" representing "parts", 30-60 issues, only one release cycle

(I've not really mentioned subtasks, but their main uses are for when you want many people working on a single issue, and/or the issue looks too big to be tackled as a single item - in both cases, breaking up the issue into more manageable chunks)

Hi Nic

Is there any advantage / disadvantage as far as reporting on 1 project vs 5 related projects? We have 5 related projects and would like to report on status, burndown, etc. across all 5 to report on the "program." We are JIRA Cloud so that may limit add-ons.


Most of the reporting in JIRA is built on filters.  So it's very easy to say stuff like "project = X" for a single project but move on to "project in (x, y, z)" when you want to go across project.  If your admins have set up and used good project categories, then "category = abc" can be even better (Category could even map on to your "program" here)

Burndowns are different - they belong to your scrum boards rather than projects, but boards also go across projects as above, so indirectly, it's the same.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,076 views 4 9
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