JIRA setup for multiple processes in the same project

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.

4 answers

1 accepted

This widget could not be displayed.

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

This widget could not be displayed.

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

This widget could not be displayed.

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.

This widget could not be displayed.

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

126 views 1 3
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