1.Why Scrum in ServiceNow / ITIL Environments is worth getting right
A game on ordering the backlog for a ticket-heavy organization forces you to weigh SLA-bound tickets against planned Product Backlog work honestly, rather than letting whichever is loudest that day win. The module then tackles a genuinely hard question directly: what a Definition of Done means when a Change Advisory Board is a real, mandatory gate rather than a formality, since CAB approval timing does not always align neatly with a Sprint boundary.
2.How it works in practice
A second game trains you to spot an ITIL-shaped impediment specifically, a CAB delay, an SLA breach risk, a mandatory change window, distinguishing it from an ordinary blocked task so it gets escalated and handled correctly rather than absorbed silently into the Sprint. This distinction matters because ITIL impediments often need organizational-level intervention that a generic 'talk to your manager' approach will not resolve.
The module closes with retrospectives that survive an ITIL audit, meaning the retrospective produces real, traceable improvement actions that satisfy both the team's own learning needs and an auditor's expectation of documented process control. The throughline is that neither framework should quietly cannibalize the other: Scrum should not pretend SLAs and change control do not exist, and ITIL discipline should not be used as an excuse to abandon Sprint-based inspection and adaptation.
3.Role reality
ITIL and Scrum answer different questions. Most teams get into trouble by using the wrong one for the question in front of them.
| Textbook theory | Delivery reality |
|---|---|
| Scrum teams manage their own Sprint scope. | A P1 incident does not care about your Sprint Backlog. It belongs to the on-call rotation, not to a silent scope swap inside the Sprint. |
| The Definition of Done means the Increment is releasable. | On a service governed by Change Management, releasable includes the runbook, the rollback plan, the monitoring alert and the CAB record. |
| A blocked task is an impediment for the Daily Scrum. | A stuck CAB approval or an SLA at risk of breach is an organisational impediment that needs escalation, not a status update. |
| Retrospectives produce team learning. | In an ITIL shop they also have to produce a traceable, documented action or they fail the auditor's expectation as well as the team's. |
| Agile means moving fast and skipping process. | You cannot agile away a Change Advisory Board on a regulated production service. You can make the Sprint respect it and still be a real Sprint. |
4.Core delivery pillars
Four places where SLA discipline and Sprint discipline have to be reconciled on purpose.
Do not let the team quietly become an operations queue wearing a Scrum board. Track the cost of emergency changes, never pretend it was zero.
Pre-approved, low-risk, repeatable work fits the Sprint cleanly. Normal changes need a planned CAB slot; missing that slot is a real impediment.
Code merged is not Done. Passed CI is not Done. The Increment is Done when the service can survive it at three in the morning on a Saturday.
A CAB delay or an SLA breach risk needs organisational-level intervention. 'Talk to your manager' will not resolve either one.
5.Numbers that survive an audit
These satisfy both the team's need to learn and an auditor's expectation of traceable control.
Tracked against Sprint disruption, not in isolation. Shows the real trade-off cost.
Time from change request submitted to CAB decision. The clock most Sprint plans forget to watch.
Trending toward zero. Each one is a Sprint plan that broke by definition.
Percentage of documented actions actually closed. The number an auditor will ask for first.
6.Situations you will be asked to handle
The module puts you inside 2 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 13.3: Game: order the backlog for a ticket-heavy org
- Lesson 13.5: Game: spot the ITIL impediment
7.Common mistakes and why they fail
Letting SLA-bound tickets silently override every Sprint plan
Treating every incoming ticket as automatically higher priority than planned Sprint work just because it has an SLA clock attached. Some SLA work is genuinely urgent; a lot of it can be sequenced without abandoning the Sprint Goal.
Treating CAB approval as outside the Definition of Done
Calling work 'done' before it has cleared a mandatory Change Advisory Board review, when that review is a real gate to production in this organization. Definition of Done should reflect the actual path to a usable Increment, CAB included.
Absorbing ITIL-shaped impediments as ordinary task delays
Treating a stuck CAB approval or an SLA breach risk as just another slow task rather than escalating it as the organizational impediment it actually is.
Running retrospectives with no auditable trail
Holding a retrospective that produces good conversation but no documented action, which fails both the team's own improvement goals and an ITIL auditor's expectation of traceable process control.
8.Questions worth asking before you commit time to this
Can Scrum and ITIL actually coexist on the same team?
Yes, but only if both sets of constraints are made explicit in planning rather than one being ignored. SLA commitments and CAB gates need to be visible inputs to Sprint Planning and the Definition of Done, not surprises that derail the Sprint after the fact.
How do you prioritize an SLA-bound ticket against planned Sprint work?
Weigh the real cost of an SLA breach against the cost of disrupting the current Sprint Goal, the same cost-of-delay thinking used elsewhere in the curriculum, rather than treating every ticket with an SLA attached as automatically top priority.
What counts as a real impediment in an ITIL environment?
A stuck Change Advisory Board approval, an SLA at genuine risk of breach, or a mandatory change window that conflicts with the Sprint plan. These need organizational escalation, not just individual effort, which is what separates them from an ordinary blocked task.
9.What to remember
- Where SLA math and Sprint math genuinely pull against each other
- What the Definition of Done means when a CAB gate is real
- A situational matrix for ITIL-shaped impediments versus ordinary delays
10.Where this sits in the Scrumling course
Run Scrum inside a ticket-heavy, SLA-driven ITIL org without pretending either framework does not exist.
About 37 minutes of lessons and decision scenarios.
- Lesson 13.1: Why Scrum and ITIL both exist
- Lesson 13.2: SLA math vs Sprint math
- Lesson 13.4: Definition of Done when CAB is real
- Lesson 13.6: Retros that survive an ITIL audit
- Lesson 13.3: Game: order the backlog for a ticket-heavy org
- Lesson 13.5: Game: spot the ITIL impediment
Assessment: Scrum in ITIL Environments quiz