How do I tie Scrum activity to Incidents?

[jure]

In the SDLC Scrum Process WIKI, it states:

SDLC Scrum Process - ServiceNow Wiki

"If required, scrum activities can be tied into IT Service Management processes such as Incident, Problem, and Change Management."

But I can't find any description of how exactly to tie Incidents to Scrum activity. I would like to understand anything about this, but specifically, I'm hoping to:

• Add an existing Incident to a Sprint Backlog
• Link a Story to an existing Incident
• Manipulate Incidents in the Planning boards just like stories, epics, etc.

[danielbilling]

Hi,

Think it's hard to provide 1 correct answer to this question. From my experience it related to the level of control you are trying to achieve as well as the scrum maturity level.

The enterprise customers i've worked with we created enhancements request from Incidents ( following the process IM -> Request fulfillment). A "ITSM platform" team was evaluating/QA the enhancement and decided if and when a story should be created. due to the large amount of enhancement request this was a vital step(filtering) to avoid spamming the SN development team.

one of the challenges is the communication flow. When, what and to whom do we post progress updates? If you are using Self service you need to decide on which records should be viewed by the customer.

Not sure this helped very much

/Daniel

[jonathonbarton]

James,

This is how we handle this at DIA.

We don't (yet) have a direct link between Incidents/Service Requests and the SDLC/StartNow process, but we're working on it.

For us:

An Incident is something that is broken and can be fixed RIGHT NOW. (Password resets, Printer jams, Replacing mice or network switches, etc.)

A Problem is something that needs more time and attention to resolve.

We have a Generic Service Request in our Service Catalog for "Everything that's not actually broken and isn't elsewhere in our Service Catalog." - Enhancement Requests for our ServiceNow installation have intake here.

If it *has* to come in as an Incident, in our process, we would create a new Problem from your Incident and set the Status of the Incident to Awaiting Problem. This *should* also stop any SLA clock that's running on the Incident.

In practice, since everything in our instance is working at least "good enough for now", users can submit Generic Service Requests for ServiceNow Enhancements.

For small requests, like extending the length of a dropdown so that long text (i.e. "Applications Development") doesn't wrap on the page, the RITM (Requested Item) is assigned to the ServiceNow Admins group. The Admins write an Enhancement Request and assign it to the SN Admins Group for scoping. Once it's scoped (which really happens simultaneously with writing the Enhancement Request, really) and put on our Development/Release calendar.

At that point, we update the RITM and let the requestor know that the Enhancement has been approved and has been placed on our Development Calendar. At that point, we close the RITM/Request.

For larger requests (Whole new catalog sections, etc.) the intake is the same up to the writing of the Enhancement Request. At that point, we assign a Task from the RITM to our ITSM Program Group, and they handle customer contact/requirements, writing the Enhancement Request and the associated Story (with Acceptance Criteria) before giving it back to the Admins for final scoping and scheduling. At that point, we tell the requestor that the Enhancement has been approved, the proposed release it'll be in, and then the Request/RITM is closed.

The requested Enhancements can also be Canceled by the Admin or ITSM teams at any point, and we notify the Requestor the reason for the decision.

Being able to tie the Requested Item to the Enhancement Request (which is tied to the Story) is on our radar.

[robpickering]

Not covering the philosophy of the "tie", but Incidents are "interruptions of service" AKA Defects and Requests are "non-interruption service desires" AKA Features.

We have UI Actions on Incident and Problem (these are out-of-box, but inactive by default) that allow our folks to "Open Enhancement" and "Open Defect" from them.   The task is then put into "Pending > Pending Development" and a referring record is added to the task to reference the Enhancement or Defect.   When the Enhancement or Defect are closed/cancelled, a Work Note is put on the source Task and it is moved back into Work in Progress.

That's how we integrated them.