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

Your Points Tracker
  • 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
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?
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

Advice on how many / how granular to go with projects:?

Hi all, we've been experiencing trouble as a business because we always tend to have one project that ends up being a bit of a dumping ground. 

I'm talking about internal facing projects - we use a separate project for public facing support.

We develop 3 products. Initially we used one project for development of all products, alerting, everything. This was awful unsurprisingly so I swiftly put an end to it splitting it up into one project per product, and also an alerting project. 

My question essentially is how granular do you go with your projects? We now have an SRE project, so in this project goes tickets regarding the deployment pipeline, monitoring, infrastructure, the usual SRE stack. We find it has become a bit of a dumping ground, or certainly the quantity of issues is pretty unmanageable.

So would you split out your projects even further or is this normal? Particularly interested in how many projects people are using and particularly how they are using them for things like an SRE team which has a hand in many things across multiple projects.

1 comment



May I ask, what do you mean by splitting into multiple projects?


In case you just split projects, using the same issue types, workflows, fields/screens, etc... I think this has no value.

In your case, since projects have become like a dumping ground, splitting would work in theory, if other projects were "restricted". What I mean by that is that (example):

Project A - has only 2 issue types (Bug,Incident) and simple config

Project B - has 3 issue types (Epic,Story,Task) and slightly more complex config

and so on.


In case you still use the same issue types/configs, imo just configure some boards, Personalization (personalized views matter) and escalation filters. That would help.

Trust me, in the end multiple projects or not, personalized view are the ones that matter.

Let's just say for example Front End devs would only want to work with Front End issues (example Component=Front End) and so on.


We were in this crossroad about 2 years ago, where for our L2 support there were 2 options:

1-Single Project with personalized views

2-Multiple projects (1 per service)


Eventually we went with option 1, and quite frankly it worked out the best, since generally we can also preserve standards easily on how we handle issues and respond to customers. Also easier KPIs, solution documentation etc.


Best Regards,



Log in or Sign up to comment

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