nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

samuel-langlois

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.

All comments

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:

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

C_Faysal _CFcon_

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

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

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

C_Faysal _CFcon_

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

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

samuel-langlois

From my experience, a Jira project is a unit which has its own release lifecycle, i.e. list of versions.

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!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

project

requirement