Jira Software and Service Management Change handling

Question

Hi everyone.

I'm hoping you can point me in the right direction or share some of your experience around this topic.

We have a number of different solution manager / development functions with their own backlog and governance using Jira Software. I think I still want to manage the actual technical change activity with Jira Service Management so that we have a single change calendar of work being applied to production.

Do any of you have similar setups? How do you manage change between Jira Software and Service Management?

One of the considerations I have is that our development functions will still likely need to interact with our non-licenced customers to clarify details or get further information and I want the reporter or other non-licenced users to be able to track the status of their change request.

One of the ways I was thinking of handling this is having 3 linked records:

* (Service Request in JSM) Request for change * Create a bug / feature request in the relevant teams backlog

* (Epic / Story in Software Backlog) Bug / Feature Request* Team declines / schedules the build + testing

* (IT Change in JSM)* CAB approves the release to production

I'm not sure if this would work well from a user visibility perspective?

I hope you can help and share some of your use cases / guidance around this.

Many thanks,
Dave

David Meredith_lho1hy · Answer

Hey @Walter Buggenhout ,

One thing that I want to understand further is where to process and manage the actual change activity. In my mind there is the:

* Request for change (defect / bug fix / feature request...)
* Backlog management (bug / feature request / maintenance...)
* Change activity (actually applying this to production, when, how, approvals etc)

It's possible to process the change activity in Jira Software in each teams individual kanban, but ideally I want to process this centrally in Jira Service Management so that we have full visibility of the change calendar. But also keeping in mind the customer communication so that they get updates appropriately.

I know many other organisations will work this way so I'm looking for examples of what works well for others before blindly trying to re-invent a change wheel.

Many thanks for your guidance :)

Walter Buggenhout · Answer

Hi @David Meredith,

Your question goes a bit beyond a simple question / answer dynamic, I'm afraid. But a good way to look at things is from the angle of planned versus unplanned work.

Everything your customers are asking or reporting (incidents, changes, service requests, ...) is - at least initially - unplanned work. It is a good thing that you have your service teams take care of that, as the core activity they usually do is manage this queue of incoming, unplanned requests. It is their main task to keep customers happy by trying to resolve issues as soon and good as possible or by keeping them informed.

Development teams plan their work. It is a well investigated fact that unplanned interrupts have a very negative impact on the speed (and even quality) of delivery of those teams. Working in sprints helps such teams focus on work that has been committed to.

But indeed, unplanned incidents or change requests sometimes need to be tackled by that development team. And as you mention in your post, your organisation too has mechanisms in place to convert the unplanned requests from the service desk into things that can be investigated, prepared and scheduled for the development team.

The main thing to keep in mind is indeed the line of communication to your end user. He/she will never be able to see the details of the tickets that are being tracked internally by the development team. So communication to the end user ideally goes through the initial service desk ticket.

The level of information that can / should be communicated to the user is status and timing. As long as that information is passed on through the service desk ticket, you're good.

Issue linking can be a critical key in connecting things together. By connecting the JSM ticket to the issues the development teams are working on, visibility can be created across your teams.

Finally, there is the matter of exchanging information the other way. I am referring to your question about obtaining more information from your end user. Just 2 small things on that: if there is something unclear about an incident the user reported, just ask for more details through the Service Desk ticket. That is a role that can be perfectly filled by your service team and incorporated in the assessment process during ticket intake. If you really need to discuss things about a bigger change and your need to speak with one another, just do so. Pick up the phone, schedule a meeting, have a pizza together; it is not because there is a service desk ticket that you can no longer talk to one another the way you would do otherwise.

Hope this is helpful!