I am working with JIRA now for quite some time. If I understand jira correctly, one would define a JIRA-project for every application we are developing. For me it worked perfectly so far. Now another team in our company wants to use JIRA as a requirements-management tool as well. All the data that is tracked in the reqirements-management has to be linked somehow to the development-issues. I know it is possible to define links between issues in different projects and I would simply define a requirements-project and link the requirement-issues to the development-issues in the dev-projects but the requirements-management-team thinks it would be best to have one single master project and have every single requirement-issue and all the dev-issues, regardless which application they belong to, in this project. I can not imagine from a development-point of view how this can work...
EDIT: we are not talking about one requirements-project and one development-project but more like 60 to 80 development-projects used by many dev-teams (ca. 15)
My question now is: what is best-practice in case you have to handle issue/bug-tracking and requirements-management with JIRA. which plugins are recommended?
From my experience, a Jira project is a unit which has its own release lifecycle, i.e. list of versions.
If things have the same release, it means they are shipped together, and thus probably need to be in the same JIRA project. You can use Issue Types to easily separate Bugs from Requirements, etc. in the same project.
If these things are not released together, they probably deserve to be in separate JIRA project.
For instance, think of publishing the release notes when a new version is released. You don't want to deal with 2 different projects at that point.
Yes, if you have different apps that are released separately, it is easier to create several projects. When you open the JIRA project of the app, you want to see all its releases, and not the releases of the other apps.
Of course, if you have several parallel branches of development (hot fix branch, service pack branch, main dev branch), do not create several projects for each of them! This would add a lot of management, moving issues from one project to another all the time.
For example, if you have a core product with independant plugins, you may want to create one project per plugin if they are released independantly. Or you may prefer to create a single project, if the plugins are released at the same time and they don't have an independant release number. But this decision is sometimes not as obvious as it looks... Try to think about what you want to appear in the "Fix Version" field on an issue.
Hope this helps!
Hey there, chrisi.
Seems like the question that you have is general. If you were to ask my personal opinion, some of the best plugins that is a must-have include:
For requirements management, you can check the list here: https://marketplace.atlassian.com/plugins/app/jira?label=Requirements+Management
You can even review the list of all the softwares that are offered by Atlassian itself in the following link:
It depends really on what you use JIRA for mainly since it is very vast and it covers pretty everything that you can think of.
i would like to use JIRA the way i did't so far, without beeing limited here because i have to share my "namespace" (Versioning, Releases) with all the other applications which would reside in the project. but that would be the case if we go the one-project way. what about permission-management?
Hey there, chrisi.
Wonderful. As for the permission management, I think that the standard permission scheme should be sufficient for a standard JIRA usage. Unless you want to enhance the current one by developing plugins:
thanks for the quick reply but that doesn't help much. the thing is, i don't think that the second scenario i described above (one-JIRA-project many applications and dev-teams) is standard JIRA usage hence the standard-permission-scheme doesn't apply.
please see also the new comments to the first answer
of course 2 seperated projects can be used..
if you decide to put all in one project it might get confusing to Layer 8.
i'd use components and some customfields to seperate these things in a single project.
but if you need more info have a look at
i forgot to make clear, that we are not talking about 1 requirements-prj and 1 development-project but more like 60 to 80 development-projects used by many dev-teams (ca. 15). in my point of view, the one-project-solution would eliminate the possiblility of a reasonable permission-management for the various dev-teams and it would of course be very confusing for the user.
i don't see any sense in having a custom field to differentiate projects if there is already the term "project" defined by jira. and if i layout my projects and applications in jira in a way that i have to define an additional custom field to to distinguish the individual applications there must be something wrong with my setup...
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 ...
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