Hello there, We have an use case that I wanted to challenge with some other Jira Service Management and Software admins. We are using Data Center solution for now. So we have our L2 receiving incidents, that they are able to qualify as impacting a given product. Our product owner must be able to get the information from the incident and to create a bug or a story on the product backlog. For the time being, the process is the following: * L2 agent transition the incident to pending for change and create a bug or a story on the product backlog. * Product Team resolve the bug/story and the fix version linked is delivered, we add with automation a comment on the incident The point is that we don't want each product owner to be an agent on the ITSM project, but they must be alerted that an incident is pending for a decision on their side (to create a bug or not for instance). So we have some issue with this process, as some Product Owner are not willing to have L2 creating work items on their backlog. Do you have any suggestion, or Jira best practices on how to be sure that we are able to have L2 and Product Owners aligned on Jira and be sure that the correct information exists on bothService Management side and Software side ? Thanks a lot!

Hi @Patrice Champet , We achieve this on our Jira Cloud site by using automation to create a bug ticket on the relevant product's backlog. The steps for this are: * Our JSM agents triage a request as being a bug for a particular product. * They select the 'Add to product backlog' checkbox (a custom field) which triggers our automation rule. * The product owner is automatically added as a participant on the request. * A ticket is automatically added to the relevant product's backlog (and linked back to the original request). * Information that had been entered onto the portal form's custom fields (e.g. steps to replicate, current behaviour) is automatically added to the product backlog ticket. The above has helped transform how our Technical Team and Product Team collaborate, making the process as lot smoother. Hope that helps, any questions, let me know. Thanks, Julia.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best way to involve Product Owners in incident Management

Patrice Champet

Hello there,

We have an use case that I wanted to challenge with some other Jira Service Management and Software admins.
We are using Data Center solution for now.

So we have our L2 receiving incidents, that they are able to qualify as impacting a given product.
Our product owner must be able to get the information from the incident and to create a bug or a story on the product backlog.
For the time being, the process is the following:

L2 agent transition the incident to pending for change and create a bug or a story on the product backlog.
Product Team resolve the bug/story and the fix version linked is delivered, we add with automation a comment on the incident

The point is that we don't want each product owner to be an agent on the ITSM project, but they must be alerted that an incident is pending for a decision on their side (to create a bug or not for instance).

So we have some issue with this process, as some Product Owner are not willing to have L2 creating work items on their backlog.

Do you have any suggestion, or Jira best practices on how to be sure that we are able to have L2 and Product Owners aligned on Jira and be sure that the correct information exists on bothService Management side and Software side ?

Thanks a lot!

Accepted answers

Julia Watson-Clarke

Hi @Patrice Champet ,

We achieve this on our Jira Cloud site by using automation to create a bug ticket on the relevant product's backlog.

The steps for this are:

Our JSM agents triage a request as being a bug for a particular product.
They select the 'Add to product backlog' checkbox (a custom field) which triggers our automation rule.
The product owner is automatically added as a participant on the request.
A ticket is automatically added to the relevant product's backlog (and linked back to the original request).
Information that had been entered onto the portal form's custom fields (e.g. steps to replicate, current behaviour) is automatically added to the product backlog ticket.

The above has helped transform how our Technical Team and Product Team collaborate, making the process as lot smoother.

Hope that helps, any questions, let me know.

Thanks,

Julia.

All comments

Julia Watson-Clarke

Hi @Patrice Champet ,

We achieve this on our Jira Cloud site by using automation to create a bug ticket on the relevant product's backlog.

The steps for this are:

Our JSM agents triage a request as being a bug for a particular product.
They select the 'Add to product backlog' checkbox (a custom field) which triggers our automation rule.
The product owner is automatically added as a participant on the request.
A ticket is automatically added to the relevant product's backlog (and linked back to the original request).
Information that had been entered onto the portal form's custom fields (e.g. steps to replicate, current behaviour) is automatically added to the product backlog ticket.

The above has helped transform how our Technical Team and Product Team collaborate, making the process as lot smoother.

Hope that helps, any questions, let me know.

Thanks,

Julia.

Stefan Stadler

see as answer sorry for that

Stefan Stadler

Hi @Patrice Champet

I can imagine of the following (and also implemented something similar already):

1. Synchronising data is easy using the Automation rules when creating a new issue. You could even create a full clone and then only adjust a few fields for example. Keeping data in sync is difficult without using an addon. For Data Center installations, I have made good experiences using the following addon: Elements Copy & Sync (clone issues, projects and epics) | Atlassian Marketplace

2. The more interesting point is how you can engage your product owners to be part of the decision process while still not putting them in the JSM project as an agent. In my opinion, this is fairly easy: Add a separate workflow step in the target projects with the product backlog and let the product owners decide about the new ticket in that step. There they could either Decline the ticket or move it to the next steps as required. You could then still have the tickets linked to each other so that you can see the status of the bugs from the incident. Also alerting is simple on that because you can add a notification on issue creation for the product backlog ticket.

Let me know, if you need more details on that or if this idea already helped you to solve your problem!

Regards,

Stefan

Patrice Champet

Hi @Julia Watson-Clarke

Thanks for your feedback.

It confirms the way we wants to collaborate betwen L2 an Product Owners.

Adding the product owners as request participants is a good point, it will help to share information from the end users and may be a good asset for Product Owners to have this direct chanel. Thanks for the suggestion !

In addition with @Stefan Stadler comments regarding the step on the product backlog, allowing a Product Owner is able to decline a bug or a story, I think that we cover the requirements.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira-service-management

jira-service-desk-data-center

jira-service-management-server

jira-service-management-data-center