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

JIRA setup for multiple processes in the same project

Øyvind Hansen1

Is there any best practise to manage software, multiple hardware and firmware processes in JIRA. They are all connected to the same product. Any thoughts on whether work should be in the same project separated with 'Components' or in separate projects in JIRA. They all have dependencies on each other, but separate teams and work style (some agile, some not). Need to keep track of future development activities, dependencies, but also bug tracking reported by testers and customers would preferrably be within the same tool. Also management would like easily to get reports on overall progress. How easily is this when split in multiple projects. Any feedback is welcome.

Accepted answers

Anand Unadkat

Hi,

If you are following diferent methodologies, you are better off creating seperate projects that have separate workflow. When you say dependencies. what do you mean by that? Is it the Coponents? Version? Issue types? If it is the issues types, you can share the same scheme across all the projects, however if it is components or versions, then you will have to create same ones across all the projects.

I hope that answers your question.

Regards

Anand

All comments

Anand Unadkat

Hi,

I hope that answers your question.

Regards

Anand

Kim Poulsen

With what you describe you are way better off having separate projects as Anand wrote. To keep the overview at the top level project you can look into ex. the Structure plugin: http://almworks.com/structure/overview.html

There are other offerings on the market I am sure. This is just one we are currently evaluating for the same purposes.

Letting each 'sub-project' work as they see most fitting and efficient for them is very important for good execution. Demanding they all use Jira for logging and tracking if they are not used to that is probably going to be enough of a challenge.

Regards, Kim

Øyvind Hansen1

Hi Anand and thank you for the reply. By dependencies I mean that if a hardware/firmware entity (say circuit board 'X' v1.2) is not realized by the given time we have multiple dependencies in SW that are blocked and needs to be reprioritized. In HW problems is not fixed in a day or a week like in SW, so it may have major impacts on the prioritizing in the project. But also there can be dependencies within HW|FW that can be blocking each others, i.e. say FPGA v1.7 not ready and such it is hard to continue with real life testing of features in the FW which again affects SW.

The project owner and respective team members would like to have a clear overview of blocked items (SW|HW|FW) and to produce reports.

So to sum it up: Dependencies within the same bounded context and across bounded contextes. Each context may have many components.

I'd say all processes (HW|FW|SW) are part of the same grand workflow, but at the daily basis there are different approaches of how to work.

But I think you are right; as long as they are not a part of the same daily workflow there should be separate projects with respective workflow. I see that it is possible to link issues between projects in JIRA which will solve the dependency question. However I think I will keep HW|FW in the same project to not over-engineer it project-management-wise.

Øyvind Hansen1

Hi Kim and thank you for your valuable input. I think you both have good views on the matter and thank you for the link, I will try it out.