How to configure Jira for a team with 3 disciplines developing 20 modules for a single prototype

[Egon Boormans]

Hello jira community, I’m currently looking into setting up Jira for our team which consists of 3 disciplines, e.g. mechanical, electrical and software designers. So we’re working towards developing housings, PCBs and software for around 20 modules. These modules go into a single prototype version. Versioning (fix version field) and the burndown is very important for the software designers, so I’m wondering shall we just create a single project and mingle the 3 disciplines? Or is it much better to create 3 different projects and link them on a higher level using e.g. an epic for each module. Or is there maybe a better solution?

[Nic Brough -Adaptavist- · Accepted solution]

It depends on how you want to work together, and what part of the config matters most to your people and reporting.

In this case, the things to consider are all about project configuration:

• Projects have distinct components
• Projects have distinct versions
• Projects have permissions for users

The two "distinct" ones may be the most important.  What I mean by "distinct" is that versions and components belong to projects, and even if you were to use shared names, they would be different versions.  Project A's Version 42 is totally independent of Project B's Version 42, and reporting will show them as two different things.  Same for components of the same name.

With the permissions, that is probably less important, but you can do things like "only allow developers in the project to edit", so if you wanted to slice up your projects by the three design groups, you might go that way.

Given some quotes from your question though,

• "These modules go into a single prototype version. Versioning (fix version field)... is very important", which screams to me "single project covering the overall product".  
• "our team which consists of 3 disciplines", team implies you're not really wanting to inflict different patterns of "only X can do Y" on sub-sets of the team, everyone should work together
• "around 20 modules. These modules go into a single prototype version" - reinforces the "one project" for the versioning.  Also suggests you could use the "component/s" field for telling people when a story affects one or several modules, again pushing you to "single project"

[Egon Boormans]

Thanks for the answer. Say we would start a single project covering the 3 disciplines, I'm wondering if the versioning and burndown would still work. This because the housings, PCBs and software binaries will need their own versioning

[Nic Brough -Adaptavist-]

Oh, ok, then I've mislead you.  If things need separate versioning, then it should probably be "project by item that needs its own version scheme".

But that doesn't stop you going on to what I'd do next - build boards by team.  A team might be drawing work from one or many projects, and may well be single or multiple disciplinary.  A board can do that, and put their work in front of them