Project and/or Product?

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 ?

 

3 answers

0 votes

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

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" 

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.

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. 

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,854 views 12 18
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot