What is a JIRA-project

[chrisi]

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?

[Samuel Langlois · Accepted solution]

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.

[chrisi]

Thanks.

vice versa, in my case it would be neccessary to have sepatate projects because i want to release different apps at different points in time with different versions!?

[Samuel Langlois]

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!

[C_ Faysal]

hi chrisi.

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

https://confluence.atlassian.com/display/JIRAKB/Using+JIRA+for+Requirements+Management

https://marketplace.atlassian.com/plugins/com.optimizory.rmsis.plugin.jira-rmsis

[chrisi]

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...

[C_ Faysal]

true.

i guess setting up permission schemes will be inevitable.

just evaluate the rmsis plugin in a testing environment and see if it fits your needs.

then outline permissions and try to seperate those two kinds of projects as good as possible

[AhmadDanial]

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:

• http://www.atlassian.com/software/greenhopper/overview
• http://www.atlassian.com/software/bonfire/overview

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:

http://www.atlassian.com/software

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.

Warm regards,

Danial

[chrisi]

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?

[AhmadDanial]

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:

https://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions

Warm regards,

Danial

[chrisi]

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