Support Operations + Agile -- How to handle projects

[Austin Klise]

We are both a professional services company (web dev/design) and a SASS shop with out of the box offerings. The layout of our dev team is "project teams" "product teams" and a "support team".

Right now JIRA is working great for our project and product teams. However, I'd like to add our support team to the mix but unsure best JIRA architecture for them ( we don't have service desk ). We've got 100s of clients that we do monthly support for so I think it might be untenable setting up new projects for each client. And we can't just attach a component to each of these since a lot of the work is custom to their stack, not a core feature.

We could setup a single support project but won't that be pretty limiting in regards to seeing history of client X bugs over the course of months and years? 

[Troy Spetz]

We use JIRA 7.9 server version.

We have a single product with 10s of customer server installations and 1000s of users.

We use OTRS to manage the Helpdesk's interaction with our users. Our Helpdesk team decides which OTRS issues need to come into our single JIRA project as improvements, defects or chores.

If you are using a JIRA project per customer, then your Helpdesk could be escalating (flipping) tickets from another CRM tool (e.g. OTRS, JIRA Service Desk) into JIRA into the correct project (e.g. defect, improvement, chore, etc).

The benefit of using JIRA Service Desk is that, I presume (as we don't use it), the issue can easily be flipped into JIRA. In our case, our Helpdesk have to do a manual cut-and-paste from OTRS tickets to JIRA issues. (While this is slower, it does have the benefit that only *real* problems come into JIRA -- due to the effort of copying the relevant OTRS ticket information into the JIRA issue.)

I agree that setting up a single project for 100s of customers would not work. It would seem that whatever your Support Team needs to log in JIRA, it should be done directly in the affected product (i.e. 1 product per JIRA project), as this is where the developer/testers will need to progress it.

Don't make the dev/test team go looking for defects/improvements/chores in other JIRA projects (i.e. outside the JIRA project they work in daily for their product).