What Scrum in ITIL and ServiceNow environments trains
ITIL and Scrum were built to solve different problems, ITIL for controlled, auditable change in an operational environment, Scrum for adaptive delivery of a product, and this module starts by taking both seriously instead of picking a side. The opening lesson explains why each framework exists and where their assumptions collide, before moving into the practical clash most teams actually face: SLA math versus Sprint math, where a support commitment measured in hours and an increment measured in a two-week Sprint pull planning in opposite directions.
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.
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.
Mistakes teams make with this material
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.
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.
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.
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.
Questions people ask
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.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
A P1 incident lands on day 4 of a 10-day Sprint. Strongest team design?
- Absorb it into the Sprint Backlog silently
- Route it to the on-call / operations rotation, and only re-plan the Sprint if the incident work is genuinely the team's
- Cancel the Sprint immediately
- Ignore it: the SLA is not the team's problem
P1s belong to on-call rotations, not to the Sprint Backlog. Absorbing them silently destroys the empirical loop the Sprint depends on.