Jira Project Structure and Best Practices

[DSell]

At the company I worked at previously they set up Jira projects functionally. e.g. a project called "software engineering", a projects called "hardware engineering", a project called "mechanical engineering". These projects were never ending. No matter what business project, if it was a software issue, it was in the "software project". One note, program management did not use Jira... it was only used by the engineers. Each team conducted their own scrum process.

At the company I am working at now, business projects are ran in Jira and engineers have tickets spanning many business projects. The business/(jira) projects are ran in scrum, but there is no way, say a software engineer can be involved in that many scrum teams:) I am sure I am not the only person that has ran into this. What are the best practices surrounding this?

[John Funk]

Hi @DSell  - This is only my opinion, but I think the way it is handled by your current company is the correct way the structure should be setup. 

However, the engineers should probably be associated with a small set of projects. In other words, Engineer Smith should be involved with Projects A, B and C but not ALL projects. And Engineer Reddy should be involved with Projects D, E and F but not all projects. Something like that. 

Now, having said that, you can create an additional board for the engineers that spans multiple projects. Just create filter that includes each project. Something like: project in (A, B, C, D, E, F, etc). Then attach that filter to the new board. 

You can then create Quick Filters by project to see individual projects at any time on the new board. Or you can click on the avatar of the Engineer to see only the issues currently assigned to that Engineer. 

[DSell]

Thank you @John Funk for the reply. I like your idea about the additional board. It would be really cool if then a sprint could be ran on that board. So say the mechanical engineers could run scrum across all the mechanical tasks in all projects.

[John Funk]

Yes, it can be - just be sure to create it as a Scrum Board when you create it. It can still be linked to the same filter. 

[DSell]

Thank you @John Funk . Where it becomes really foggy is when, say the software team is building software that will be used in many business projects and maybe just tweaked for a different end customer or vehicle. Is there a way that common fixversions can be used in different Jira projects?

[John Funk]

We tend to use Components for things like that. Components are unique per project, but you can create the same value in every project. Then you can run queries across the instance based on the Component value. 

[DSell]

I will look at that. I have not used components for this in the past. Can you point me in the right direction for guidelines/best practices?

[John Funk]

I don't know there is anything written up about them as far as best practices, but this article might help guide you.

https://confluence.atlassian.com/adminjiraserver/managing-components-938847187.html

[DSell]

Hello John,

Thank you for your help. You have given me a lot to think about and different prospectives. I do wonder what problems I would run into sitting it up like the attached. The customer projects (towards the bottom) are pretty much boiler plate stuff running through the same phases with a design tweak here and there. On the advanced engineering side scrum is important both within the functional teams working across all projects, and also different scrum teams working more at the individual level.

[John Funk]

That should work

[DSell]

Thank you John!  One last question, would you agree that parallel sprints must be enabled? So say the SW team can run a sprint with issues spanning all fixversions and at the same time Project Management can run a sprint on just their one fixversion.

[John Funk]

Yes parallel sprints is probably the route to go