DoD for incidents

So, incident management and Scrum. Unplanned work vs. planned work. The shear definition of things that pop up unexpectedly vs. sprints with fixed work that cannot be changed. ITIL vs. Agile. And how to connect both.

One of the ways to connect different ways of working with different goals, is to try to speak the same language and align communication. With this goal in mind, I’m experimenting with what I call the Definition of Done for Incidents. In this way at the end of the incident management process, you know what needs to be done. And when asked the question: “Are you done done?”, you can answer: “Yes”.

I’m suggesting that an incident is done, if:

  • All the incident AC’s are met
  • (Temporary) fix is available on production
  • Live (temporary) fix is verified by reporter/enduser/customer
  • Service is back to normal service level (SLA)
  • Documentation is updated (if needed)
  • Problem ticket is created if temp fix or critical incident
  • The incident ticket is updated

My questions to you are: What do you think? What am I missing? What is unnecessary? What other feedback do you have?

Leave a Reply

Your email address will not be published. Required fields are marked *