Design Decision - Single project multiple components or multiple projects?

[Ranjani Padmanabhan]

Good evening,

I am trying to architect a solution for a Global Operations Service comprising of at least 8 teams. Please note that the users are not engineers but they heavily interact with them. The primary purpose of having the JIRA solution is to have interaction with Engineering, tracking global roll outs (code releases, provisioning, breakfixes), and tracking day to day operational activities within the team. These teams currently have their own siloed ways of operating (process-wise) right now and the intention is to bring them together through JIRA.

Given this situation, I proposed having one JIRA project/queue and utilizing components heavily. I proposed naming conventions like PROD-xyz (to indicate the products within this service - there are 3), REGION-xyz (US, Europe etc), FUNC-xyz (represent functionality like provisioning, capacity). A combination of these components would yield in a team specific view which can be used as a JQL filter for Kanban boards. Please note the teams cut across products and functions (not regions though).

Expecting about 100 users to use this design with say most of them just getting used to the tool, is this design too complicated? For instance, if a component is not added (because human error, duh), then the filter results / boards will not reflect the specific issue. Defining controls around components is hard.

So my question really is: Is my solution scalable? Would it be more advisable to use >1 project for this use case? If so, should they be done per team or per product? 

Thank you for reading. Feel free to ask questions if there is not enough clarity.

[Jacob Vu]

Hi! I work for an org where we have projects per team (where some teams manage products), just some thoughts:

• Can you get buy-in from everyone to populate the right information when creating epics/stories/etc so that your filters work properly? If they don't do it properly, do you have someone who will manage this and ensure that users are following the process that you laid out? Otherwise it sounds like your JQL filters can get messy quickly and the data can be poor
• Do the teams follow the same workflows? What happens if one team decides that the existing workflow doesn't work for them? If you have one project, you'd need buy-in from all of the teams to come to a workflow that works for everyone (I'd suggest this doesn't exist). 

[Ranjani Padmanabhan]

Hi Jacob,

Thank you for your response.

To answer your first question: yes, I think for the single project solution we would need a 'scrum master' to ensure QA checks. I can request a dedicated resource to be assigned for this.

For the second bullet point, our enterprise has restricted JIRA workflows. So pretty much all projects end having the same workflow. 

So I guess the answer seems to tend towards this: yes my solution works, IF there is a resource who can ensure quality. 

[Jacob Vu]

Hi Ranjani,

I think it would work for now if you have a resource available to ensure quality, but I'm not sure that it would be scalable. My concern would be that if the workload increases such that having one person is not enough, you'll have to hire more and more people as the organization grows.

An alternative would be to use a project per team (including product teams) and that would remove your need to have an org level person to QA, but you might have lots more Kanban boards (e.g. one per team, one per project if it's cross functional, etc).

Things to think about.