Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Jira Project Structure and Best Practices

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?

1 answer

0 votes
John Funk Community Leader Jan 18, 2021

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. 

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 Community Leader Jan 18, 2021

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. 

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 Community Leader Jan 19, 2021

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. 

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 Community Leader Jan 20, 2021

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

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.

2021-01-24_13h13_34.jpg

Like John Funk likes this
John Funk Community Leader Jan 24, 2021

That should work

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 Community Leader Jan 25, 2021

Yes parallel sprints is probably the route to go 

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...

314 views 9 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you