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!
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)
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.
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
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!
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