Issue process for Bug reports - Move or Clone?

[Michael Hart]

Current process

1. Client reports problem
2. Support confirms problem is a bug
3. Support clones the issue
4. Original issue stays in Support project, cloned issue moves to Devs project
5. Original and clone sit around for (however long)
6. Bug is fixed
7. Clone is closed
8. Support and client confirm the fix in the original and resolves the original, or, clones the original again if more work needed
9. Rinse repeat 4-8

New process

Is this reasonable, or at least standard process for most organizations?

1. Client reports problem
2. Support confirms problem is a bug
3. Support moves the issue to Devs project
4. Bug is fixed
5. Devs moves issue to Support project
6. Support and client confirm the fix, or, Support moves back to Devs project if more work needed
7. Rinse repeat 3-6

Does the new process seem logical?

I'm not sure if there's a better way of doing things. I feel like this is probably the best way to manage and track issues that are reported as one thing, but are discovered to be bugs. I'm unsure if Jira has it's own kind of SOP for the "official" way of doing things.

The problem(s) I'm trying to solve

• In my own queue alone, over 95% of the issues that are assigned to me have been cloned and are waiting for Devs; a large number of issues in the Support queue that Support has no control over.
• The SLAs for the original issues are put into reports for management
• We're duplicating information that already exists
• We're increasing the number of places that information might be stored (comments sections for each original and cloned issue)
• Excessive email notifications each time work is done on either issue

Why are they doing it the way they are?

The reasoning that I was given was something to the affect of

We want to 'keep track' of what bugs customers have reported, that are being handled by the Devs.

I asked why we don't just check the Devs projects when we want to know this, and I never really got a solid answer.

If there is a better way of managing this, please let me know. Thanks.

[Fabian Lim · Accepted solution]

Hi @Michael Hart

• For your process, moving issues between projects for assignments becomes very messy. 
• My suggestion is to create a linked task/story from the bug ticket in the portal to the development team. Then the dev team can work on the fix and the bug ticket stays in "dev team investigating" status.  
• Use the "causes" relationship type
• Once the task/story is fixed, the dev team communications with the support team via comments that a fix is ready and then the support team manages the communication to the client.  
• When duplicate bugs are reported, you can link them to the original ticket so see the count of how many times it was reported. 
• No need to move tickets between projects this way and you keep the history of the original ticket and the dev ticket created.

I hope this helps.

[Michael Hart]

Hi @Fabian Lim ,

Thanks for the response!

The solution your suggesting sounds very similar to what we currently have in place. Not 1:1, but pretty close. I guess that could be a good thing?

I think maybe my perspective on the matter is wrong. Could you explain what you mean when you say "messy"?

I see this as a problem because it's a kind of "visual clutter" for Support staff. It adds a kind of fog to what is a true Support issue in briefings.

It is true that we can change the status to "Dev team investigating", and that we can pause the SLA for a given status, but it seems bizarre to have an issue assigned to me when someone else is doing the work to fix the problem. I don't grasp the logic of that.

Example: If a car is broken, you don't assign the task of repairing the car to the receptionist just because he answered the phone. You pass the assignment (move) to the mechanic, so he can detail the problem, fix it, and explain the solution, then provide that information (move back) to the receptionist, who provides that information in a comprehensible manner.

Maybe you can clarify what I'm not seeing here? It's a very odd way of doing things in my mind.

[Fabian Lim]

Hi @Michael Hart

It's messy because you will have different IDs every time you move it. You also have to consider the workflows between the projects. If they are not the same you will always have to map the move the proper status.

Now, your comment about leaving that receptionist ticket open. It's more about process and triaging the issue. You don't want a mechanic answering 20 issues of the same thing, when the issue is already known and you can just tell the customer. In our process, when we know it's a know sw issues we close the tickets and let them know we have a bug open. When a fix is done, we can refer to the link tickets and let the customers know that the issue is fixed.

I hope this helps. 

[Michael Hart]

@Fabian LimI think that makes sense. It's not quite what I had hoped for, but I think I can accept that.

Thanks!

[Julien Peyrade _ Elements]

Hello @Michael Hart 

I agree with this other response, this process will end up quite messy.

Ideally, you want your devs to only have to work in their dev projects, and your support team to stay in the Support project.

If you don't mind using paid add-ons, there are several that have been created specifically for the purpose of issue escalation between support and software teams.

Full disclosure, I'm the Product Manager of one of those apps, Elements Copy & Sync which simplify issue escalation.

What you can do with the app is copy issues from your support project to any dev project, while fully customizing which data is copied or not, automatically link the issues, and keep them perfectly synchronized.

It means: 

- comments made in either issue can be automatically copied to the synchronized issues (or not, you can control if you want to or not), so that your software team has a direct access to all the contextual information that might have been exchanged through comments in the support issue

- you can keep the workflow status of synchronized issues mapped to one another, which means that, for example, if the software ticket is closed, your support ticket can be automatically set to a new status which indicates that the issue has been fixed, with no action needed on your support team parts

Additionally, issue escalation can be done automatically, meaning that if your support team changes the status of the support ticket to "Escalated to dev team" (or whichever status), a copy of the ticket can be automatically created in a specific software project of your chosing.

We have many more example in our documentation.

The app is free for 30 days, (and stays free if your instance is under 10 users), so feel free to give it a try, and don't hesitate to tell reach our Support if you have any question.

Kind regards,

Julien

[Michael Hart]

Hi @Julien Peyrade _ Elements ,

Thank you for the information. It does seem a bit frustrating to hear that this seems to be how things are designed to work in Jira. The "clutter factor" is the primary concern here for me, along with some of the other problems listed, which your product addresses.

I'll run the info provided by the team to see what they think.

Honestly, I'm really not very happy with how Atlassian appears to have designed their systems in this regard. To me, it doesn't seem intuitive or logical at all that someone would have an open issue assigned to them, but not to be the primary party who would be fixing/applying the solution for said problem.

It confuses management.

It creates extra scenarios I have to account for in SLA configuration.

It makes it feel like Support has way more problems than they do - it is mentally draining to see a steadily rising number of issues that cannot be closed in our work queues.

If nothing else, I appreciate that at least a few companies out there understand this concern and are trying to do something about it.