Dear community,
As we move to Jira Service Management and use its customer portal for Change and Incidents, we decided to keep all Requests for Change in a central demand container. In other words, our DevOps team won't need to clone/link/move every request raised by customer to a change ticket, but instead follow through end to end with the originally generated change/request for change ticket. The idea behind is that we don't need to maintain two tickets for the same issue, or set up automation, and customers get upmost transparency.
At the same time we'd like to keep historical project containers per application. They contain all other team/app-related issues (defects, tasks), and also grasp the Change tickets in its Kanban by "impacted service" field.
It all seems to work out fine except fixed versions and release management, since Jira's release function requires all released tickets to be in the same container. But we would have for each application, tickets in both 1) the central demand container 2) the application container.
Any suggestion/correction on the above approach? How can we meet the 3 goals at the same time?
1) customer transparency
2) no ticket duplication
3) per product/app release management
Many thanks in advance!
Y
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.