What is the best way to organize JIRA?

[Rodrigo Arruda]

What is the best way to organize a product in JIRA, with different areas like client support, agile development, QA, etc?

Would you go on different projects, different issue types or with Workflow permissions?

[Raymond Lai · Accepted solution]

Hi Rodrigo,

While there's no definite answer, I can impart some experience with my JIRA instance.

Client Support Queue: We have a single project that encapsulates the entire support group. For each issue type, we have custom workflows to automatically assign tickets to the owner of each product. Custom permissions are set up to ensure that clients only see their own tickets, and of course, our support team can see everything.

Development Queue: We have a project for each product we develop. We started off with the product owners defining their own issue types, but over time we found moving tickets between projects to be too confusing. We ended up conducting a cross-team exercise to standardize issue types across all of our projects to reduce cross-team confusion. However, even with the same issue types we developed custom workflow schemes for each project as we recognize each team does things differently.

I've developed the USE philosophy when it comes to JIRA projects:

Usability - The system must be "brain-dead" simple. All workflows has to be written in plain English, and must be logically flowing.

Sustainability - Schemes (permissioning, workflow, etc.) should not overlap eachother without a good reason to. This will allow you to reuse as much existing work in the system as possible.

Security - Users should only be able to see and execute actions appropriate to their organizational role, but security should not be used as an excuse to limit appropriate access

[Rodrigo Arruda]

I couldn't agree more. I think this is the best way and I'm trying to get it. Unfortunately I have a division made by workflow. One of the reasons is communication between teams, like support and dev. Any suggestion? I've just thought, I could do that with notifications, right? This way I can announce support team that a new feature has been done.

[Raymond Lai]

I was at the Summit, and I had the opporunity to do a informal poll amongst attendees and Atlassians regarding this.

The "standard" is to have two distinct "queues", one for the support desk and another for dev tasks. Each queue would then be set up a separate project of projects. For example:

- A singular project called "Support Desk" with key "SUPPORT" for all your client-facint support desk tickets. These tickets would usually originate from clients, and clients would have full visibility over their own tickets, as well as tickets they are "participating" (or watching)

- Depending on how your development team(s) work, you may want to create a single dev project or many dev projects to accomodate the internal task queue. The internal queue is off limits to clients and would contain your usual internal issues such as bugs, new features, improvements, etc.

Of course, there are variations of the same theme. You can choose to have a separate project for your IT team to track deployments and outages. You can have additional projects for your sub-development teams.

The method you bring the two queues together is to use issue links. Once the issues are linked, developers can follow the trail of breadcrumbs to see the original client request, but since the clients don't have access to the internal queue, they won't be able to see the actual internal ticket. Having your support team manually create internal tickets and then link them to the client-facing tickets can be a drag, but there are several free plugins that offer a "Clone, Move, and Link" function" that we've found very handy. One of which is provided by Customware called "Customware JIRA utilities"

The question is what to do with the client-facing ticket after a internal ticket has been launched.... but that's a topic for another thread...

[Rodrigo Arruda]

I couldn't agree more. I think this is the best way and I'm trying to get it.

Unfortunately I have a division made by workflow. One of the reasons is communication between teams, like support and dev. Any suggestion? I've just thought, I could do that with notifications, right? This way I can announce support team that a new feature has been done.