JIRA and CCB

[Neeraj Bachani]

In one of the projects I am part of, the customer raises "bugs" that goes to the CCB for approval. 

The problem here is that everything goes to CCB for approval thereby creating a bottleneck and even minor changes/hotfixes which anyway would have been approved by CCB are also part of it.

Are there any practices around:

1. Classification of bugs/tickets into whether it is for CCB or not.

2. Translation of these bugs/tickets into right category (Epics that are huge, tasks that are small etc) and then creating a new work item type accordingly.

Thanks 

[Sudarshan · Accepted solution]

Hello @Neeraj Bachani 

Is CCB - Change Control Board.?

if yes, then here is my view point.

The way how you want your workflow to happen is your team decision with your clients and stakeholders.
check here on how to configure workflow in jira

What can be done:
Instead of having 2 separate boards , why not make it one.?

you can set a workflow with 2 phases - before CCB acceptance - this is the place where your support or business analyst will check if this change is required or not.
if its not needed, set the status to closed.

and after CCB acceptance (this is where your dev team will see the ticket) - and when the dev team finishes it the end state is "Done".

to address the bottle neck, you will have to categories the  incoming tickets and then educate the team about it.

[Eva Kasiak]

G'day @Neeraj Bachani 

are your customers involved within your Jira instance or external to it? I would give it a try and figure out how to triage the customer raised bugs as early as possible. If you don't have Jira Service Desk and use Jira only the option could be to create an "external issue type" which could be a customer-facing one - if for some reason it's not feasible to bring customers into internal Jira. 

You can read more about it here How to allow users to create issues anonymously  

You could create a Jira issue with a dedicated/custom fields scheme (or use the Jira issue template app from the Marketplace). Each customer while raising a bug would need to provide the information you want to gather/have in place/pass onto devs or other teams. Having such structured data would make life easier and ready for potential automation and triage/filtering - having specific input data from the client you configure Jira to decide whether to route this to CCB.

With this solution, the initial bottleneck would be resolved as you would use Jira templates/custom fields/then rules to triage automatically the issues. If your company policy is to let customers into Jira then it's even better/easier and you can work this out within workflows and boards.

As for the 2nd point, you described I'd say that if these are Bug issue types then normally you don't create Epics/Tasks our of these, and you "drag the Bug issue type" from the moment when it was raised by the customer (as a Bug issue type) through the CCB (or not if not needed) towards the dev fix and QA and DONE.

If you still would need to create other issue types based on this one - you can go with automatic rules again and convert the issue from Bug-type to Dev Task (again would question twice why you would like to do it?) and then place accordingly to the board and appreciate status.