Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,412,131
Community Members
 
Community Events
169
Community Groups

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

Hi,

 

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,

Jimmy

Comment

Log in or Sign up to comment