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

Advice on how to organize a product backlog and code-stream-oriented bug tickets

Dave Drexler

Hi folks - I have product managers wanting to manage higher-level functionality-oriented requirements in a backlog, and developers and QA people wanting to manage bugs through a fairly standard development process, with the bugs categorized by their containing code streams.

Right now, I have projects set up that correspond to code streams, which means that implementing a bit of functionality could result in issues being generated in multiple projects. But the Product Managers want to see all the work that needs doing and is being done in one backlog project for each product.

What's the best way to organize the projects? Is there a way to create parent and child projects?

Accepted answers

Ramiro P

Hi Dave,

If I understand well you could the same as in my company. When you have for example an error that is affecting multiple projects, you could clone the issues and modify it so it corresponds to other projects. Or there are other ways too using the Script Runner plugin.

But first, is that the issue, you have the same error in multiple projects?

All comments

Ramiro P

Hi Dave,

But first, is that the issue, you have the same error in multiple projects?

Ramiro P

Hi Dave,

But first, is that the issue, you have the same error in multiple projects?

Dave Drexler

Hi Ramiro - no, not really. In my case, I need to tie multiple tickets together under one "parent" ticket.

For example, assume for one product we have two code streams: one for the UI and one for the database. If the product manager wants to add a new field to the product UI, that will require work both in the UI and in the database.

The product manager wants to manage (prioritize, vote on, see status) the functional change in one parent issue, but the actual work would require two child tickets - one for the change to the UI and one for the change to the db.

Does that make sense?

Ramiro P

Yes, I think it makes sense. Basically what is the issue of having exactly how you described? That is one Parent Issue with two Sub-tasks where you can describe in each one the changes for every case.

Dave Drexler

Sub-task issues are in the same project as the parent issue. I'm looking for essentially the same relationship, but in different projects.

We want to keep the child projects in separate projects because the code streams are versioned separately. I think the versioning capabilities only apply at the project level.