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; } } }

Project and/or Product?

Erik Erik

In JIRA everything is a project but in real life we've product and project. Versions are managed for product, not project. Also, sprints and requirements are done inside projects, but not only for requirements. So it could be nice to be able to identify some requirements inside a project, allocate them to a product which is not the project object and also attach them to a version of this product.

How can i do that in JIRA ? Don't you think that make a clear distinction between project and product could help ?

Accepted answers

All comments

Nic Brough -Adaptavist-

"Versions are managed for product" - that's quite a strong requirement that leads me straight into "use a JIRA project to represent each product". In other words, reduce the distinction between jira-project and product. It's actually the way JIRA was built, to have a set of products with their maintenance being represented by projects. (With the ability to have other projects for doing things outside the product, like requirements, which you can then move into product/projects if they turn out to be related to a single product, or link to if they're cross-project, or even create as Epics if you have Agile)

There's quite a lot of flexibility in JIRA, but your product versions definitely suggest a 1:1 product = project setup.

Erik Erik

Yes I understand. But when you create an "issue" in a project, you cannot allocate it to a version of another project (product for me), right ?

And requirements are requirements for a product, not a project so having one jira-project for a product and one or more jira-projects for projects lead to some problems when I want to "explain" that these projects have impacts on my product, i.e. create new requirements or more complicated, modify existing requirements.

Definitively, projects are not products and using the same concept in a tool necessarily generates problems or frustrations because you do not manage these 2 objects the same way.

I will try to see if some plugins can help...maybe "Structure"

Nic Brough -Adaptavist-

That's correct, but you're now contradicting the setup you mentioned earlier. If you use a project = product mapping, then "I create an issue in a project and can't allocate it to a version in another project" is correct. Because you're raising issues for another product. Put the issue in the right project and it will work fine. Your setup of "one project per product" is by far the best solution for what you want to do. The next best setup for you is to have one giant project and use fields to define the products within it, but that's going to get very messy on release management, as you'll have to keep all your versions separate. The bit about requirements misses the point a bit. Requirements could start off without a product because when you first come up with one, you don't really know whether it's going to affect one product or many, and you don't necessarily know which one(s) you want to affect. In a lot of cases, it's actually obvious immediately, so the instinct is to create a requirement in the right product/project but actually, the best thing to do is keep them separately until the analysis uncovers all the products they may affect. Then you can move them into the right project, or better, use them as Epics so they can cross any product. In fact, that's a standard recommendation - do the requirements in Confluence where you can talk about them, define use cases, discuss how to test them, outline potential problems and document them in as much detail as you want. When they're well defined, create an Epic in JIRA that says "here's a requirement" and link back to all the Confluence stuff.

John Pisani

I'm with you Erik (which is what brings me here).

Products have backlogs, version history & road maps, source code and artifacts etc.

Projects (for me anyway) deliver, or evolve Products. Sometimes more than one Product needs to be affected as part of any given project.

Similarly, products might be affected without (what we call) a project, for instance as part of BAU maintenance.

Hope you got yourself into a comfortable position.

I definitely agree with the Jira Project per Product approach. The Jira project live for as long as the product is alive. Just as we have one source-control repository with the entire history of its existence.

I'm reintroducing myself to Jira as I write in a new organisation after using a similar open source platform for about 6 years. I'm looking for the best ways to be able to manage multiple Products across many Projects and at a higher level, the entire Program of work. Our teams manage many Products and participate in many projects.

Wish me luck.

Ryan Jones_514r31

John, did you come to a conclusion and are you using Jira projects as products? Any lessons learned to share? Thx

John Pisani

100%.

1 x Jira "project" = 1 x software product - will always be my preference.

Projects start, have a duration and they end. That's why I wish JIRA didn't embed the term so deep in it's roots (just like every work item being called an Issue). It makes introducing Product Management to a traditional Project Management environment just that little bit more challenging.

Advice I'd give is to empathise with a Project Manager with a budget and a deadline and give them what they need for their reporting with other attributes (labels etc) against your work items.

Good luck mate

Matthew Murphy_3vipsl

I like that setup, however I struggle managing developers who span multiple products.

Do you have a recommendation for how you manage that?