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

[harleythorne]

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.

[Gezim Shehu [Communardo]]

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