Best Practices for Setting Up a Project

[Katie Nyberg]

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

OR

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!

[Nic Brough -Adaptavist-]

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)

[Adrian Bishop]

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.

Thanks

[Nic Brough -Adaptavist-]

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.