Service Strategy
Golden Rule
Nothing moves forward without a signed Charter or Business Case. No design work, no resource allocation, no development sprint may begin until the relevant business authority has formally approved a Service Charter or equivalent mandate. This is the organisation's explicit Go / No-Go decision.
The Charter does not need to be a heavy document — two to four pages is sufficient — but it must clearly state the why, the what, the expected business outcomes, the budget envelope, and the name of the empowered sponsor who is accountable. In ITIL 4 terms this is the trigger that formally places an initiative into the Service Value System (SVS) — it converts an opportunity or demand signal into a committed item on the Service Portfolio Pipeline.
Critical distinction: ServiceNow ticket vs strategic initiative
A ServiceNow (or any ITSM) ticket created in Service Operations is, by default, an operational task — an incident, a service request, or a problem record. It lives and dies in Service Operations unless a business decision is made to elevate it.
The test is simple: Does resolving this ticket require new or changed capability, resources, budget, or architecture? If yes, it is no longer purely operational — it warrants a Charter and Business Case review. Without that review, placing a 2-day-old ServiceNow ticket onto a Jira Kanban or Scrum board is premature and bypasses the most critical governance step in the entire lifecycle.
The Charter / Business Case is the go/no-go gate between Service Operations and the Service Portfolio Pipeline. It is not optional, not bureaucratic overhead — it is the organisation formally deciding to invest time, money, and people.
ITIL v3 & v4 alignment on the Charter trigger:
- ITIL v3 (Service Strategy): The Business Case initiates entry into the Service Portfolio Pipeline. It validates Utility (fit for purpose) and Warranty (fit for use) before any design or build activity begins. Service Portfolio Management owns this gate.
- ITIL 4 (Service Value System): The Charter maps to the Engage and Plan activities of the Service Value Chain. It formally converts a Demand or Opportunity signal into a committed service initiative. The Portfolio Management practice governs this decision.
- In both versions: A ticket that warrants strategic appraisal must be escalated to the relevant Business Function Product Owner, who decides whether to raise a Charter and add the initiative to the groomed Product Owner backlog — thereby entering the Service Portfolio Pipeline under their functional area.
Practical example
A ServiceNow ticket is raised: "Users cannot export reports from the Finance system." Day 1 it is an incident — restore service. By day 3 it is still open and analysis reveals the export function needs a full architectural change. At this point it is not a Jira card yet. The Head of Finance (Product Owner) must first review it, agree it warrants a Charter, sign off a Business Case, and add the resulting user story to their groomed Product Owner backlog. Only then does it move to a Jira Scrum or Kanban board — with scope, budget, and priority agreed.
- Identify the business problem or opportunity clearly — not the technology solution.
- Define measurable outcomes: cost reduction, cycle-time improvement, user satisfaction uplift.
- Confirm the initiative is financially viable and aligned to organisational strategy — this is the Business Case.
- The Product Owner for the relevant Business Function is the accountable decision-maker who elevates an operational ticket to a strategic initiative by raising a Charter.
- Record the approved initiative in the Service Portfolio under "Pipeline" — it is now a tracked commitment, visible to the organisation.
- In ITIL 4 terms, the Service Portfolio Pipeline feeds directly into the Service Value Stream — the sequence of activities from demand to value delivery.
Skipping the Charter is the single biggest cause of scope creep, wasted design effort, and failed projects. It is not bureaucracy — it is the organisation's formal decision to invest. A Jira board without a Charter is a to-do list, not a managed project.
Gate → Service Design & Product Owner Backlog · all must be approved
- Signed Service Charter / Business Case — sponsor + CIO; scope, outcomes & budget envelope.
- ServiceNow ticket formally escalated by the Business Function Product Owner — who confirms it warrants strategic appraisal beyond Service Operations.
- Logged in the Service Portfolio Pipeline and ranked on the Product Owner's groomed backlog.
- Utility (fit for purpose) and Warranty (fit for use) outcomes agreed — in both ITIL v3 and v4 terms, Value = Utility + Warranty.
- Measurable target outcomes agreed (cost, cycle-time, satisfaction).
- Demand & Patterns of Business Activity (PBA — ITIL v3) / Demand and Opportunity signals (ITIL v4) understood.
Who opens the gate: The Business-Function Product Owner — not the Scrum Master, not the development team, not the ServiceNow queue manager. The Product Owner is the sole authority who decides whether an operational ticket warrants entry to the Service Portfolio Pipeline and the groomed backlog. Without this decision, no Jira card is created, no sprint is planned, and no resources are allocated. This is the foundational governance act that makes ITIL v3 Service Design, ITIL v4 Design & Transition, and Continual Service Improvement all possible.
Service Design
Prerequisite
Design only begins once the Charter exists. High-level conceptual exploration is permitted before Charter sign-off, but no formal design artefacts, SLA commitments, or architectural decisions should be baselined until Strategy has approved the mandate.
Service Design translates the Charter's business outcomes into a blueprint across five aspects: the service solution itself, the processes that will support it, the metrics that will prove it is working, the technical architecture, and the management tools required. In ITIL 4, this maps to the Design & Transition activity in the Service Value Chain — converting Charter-approved backlog items into build-ready specifications.
Design the warranty, not just the utility
It is tempting to design only the features (Utility). Design must equally specify Availability targets, Capacity thresholds, Continuity requirements, and Security controls. A service that works brilliantly but is unavailable 20% of the time delivers no value. The Product Owner must confirm that both Utility and Warranty criteria are captured in the user story acceptance criteria before grooming is complete.
Xray testing in Service Design:
Where Jira is the project tool and Xray is the test management plugin, the acceptance criteria on each groomed user story become the Xray test cases during Service Design. This is not a Transition activity — it starts here. The Product Owner, working with the team during backlog grooming, defines acceptance criteria precisely enough that they can be translated directly into Xray test scripts. This ensures that what is designed (Utility + Warranty) matches exactly what will be tested before the Product Owner accepts a story as Done.
- Each user story in the groomed backlog should have acceptance criteria that map 1:1 to Xray test cases.
- The Product Owner reviews and signs off the Xray test case design — not just the feature specification.
- Test coverage is agreed at Design stage, before build begins — not retrospectively during Transition.
- Produce a Service Design Package (SDP) that Transition will use as its build specification.
- Negotiate and baseline SLAs with the business before development begins — not after.
- Confirm supplier and OLA arrangements so third-party obligations are understood upfront.
- Define the test acceptance criteria that UAT will later verify — Design sets the bar that Testing must clear.
Gate → Service Transition · all must be approved
- Service Design Package (SDP) baselined and signed off.
- SLAs, OLAs & Underpinning Contracts agreed with the business — before build.
- Availability, Capacity, Continuity & Security designed to target (the warranty).
- Architecture approved by the Design Authority.
- UAT / test acceptance criteria documented, traceable to outcomes, and entered as Xray test cases in Jira — ready for execution in Transition.
- Product Owner has confirmed acceptance criteria on all in-scope user stories — Utility and Warranty both specified.
Who opens the gate: Service Owner + Design Authority, with Service Level Management sign-off from the business function. The Product Owner confirms that the groomed backlog items carry sufficient acceptance criteria for Xray test case creation — without this, Transition cannot validate the build against business intent.
Service Transition
Gate
UAT sign-off is the gate to go-live. No service or change may move into live production without a formally signed User Acceptance Test record. This is non-negotiable in both ITIL v3 (Service Validation & Testing process) and ITIL 4 (Service Validation within Design & Transition).
UAT must be conducted by the actual business users who will operate or consume the service. They are the only ones qualified to confirm that the service is fit for purpose and fit for use from a business perspective. In Scrum terms, the Product Owner is the business proxy who accepts or rejects each user story at the Sprint Review — this acceptance is the formal UAT gate before any story is marked Done.
Xray testing: from acceptance criteria to Done
Where Xray is used within Jira Scrum or Kanban boards, the Xray test cases — written during Service Design against the user story acceptance criteria — are executed during Service Transition. A user story is only eligible for Product Owner acceptance at Sprint Review when all Xray test cases linked to that story are in Passed status. This creates a traceable, auditable chain: Charter → acceptance criteria → Xray test → PO acceptance → Done.
The Product Owner reviews the Xray test results as evidence that the story is fit for purpose (Utility) and fit for use (Warranty) before confirming acceptance. A demo without passing Xray evidence is not sufficient for Done status.
Blue/Green deployment and ITIL Release & Deployment:
Blue/Green (or Blue/Green/Canary) deployment is the modern implementation of ITIL's Release & Deployment Management process. The Blue environment is the current live production environment; the Green environment is the new release staged and tested. Traffic is switched to Green only after Xray tests pass and the Product Owner confirms acceptance. If issues arise post-switch, rollback to Blue is near-instantaneous — satisfying ITIL's requirement for a tested, documented rollback procedure before CAB approval.
- The Product Owner confirms Go/No-Go for the Blue→Green switch, having reviewed Xray test evidence.
- Knowledge articles and runbooks are updated in the Green environment before the switch — never after.
- CAB (Change Advisory Board) authorisation of the release is recorded, even in an agile context.
What a valid UAT / Xray acceptance pack contains
Linked Xray test cases with Pass/Fail status for each scenario, dated test execution records evidencing every test step, Sprint Review acceptance recorded in Jira (Product Owner accepted/rejected per story), and a defect log showing all issues raised and resolved prior to acceptance. Verbal approval and a live demo alone are not sufficient evidence.
- Regression testing: Prove that existing functionality has not been broken — every related workflow is tested, not just the new feature. Xray regression test suites handle this systematically.
- Performance testing: Test under realistic load conditions, not just functional correctness.
- Rollback plan: Every release must have a tested, documented rollback procedure (Blue environment ready) before CAB approves go-live.
- Knowledge transfer: Service Desk and Operations teams receive training and updated knowledge articles before go-live, never after.
- Post-Implementation Review (PIR): Scheduled within 30 days of go-live to confirm the service is delivering the Charter's stated benefits — closing the loop back to Service Strategy.
The cost of a defect found in UAT / Xray testing is a fraction of the cost of the same defect found in production. Testing is an investment, not a delay. The Product Owner who insists on Xray evidence before acceptance is protecting the business, not obstructing the team.
Gate → Service Operations (go-live) · all must be approved
- Xray test pack complete — all linked test cases in Passed status; defect log cleared.
- Product Owner acceptance at Sprint Review — story accepted as Done against agreed acceptance criteria.
- CAB authorisation of the change & release recorded.
- Tested, documented rollback plan (Blue environment ready for instant revert).
- Regression + performance tests passed.
- Service Desk & Operations trained; knowledge articles published before go-live.
- Post-Implementation Review scheduled within 30 days.
- Blue→Green deployment switch authorised by the Product Owner on the basis of Xray evidence.
Who opens the gate: Product Owner (business acceptance via Xray evidence + Sprint Review) + Change Advisory Board (governance). The Product Owner's acceptance is the business confirmation that Utility and Warranty have been delivered. No PO acceptance on file = no Blue→Green switch = no go-live.
Service Operations
Prime Directive
Stability at all costs. The single overriding goal of Service Operations is to keep live services running and users productive. Every action must first be evaluated through this lens: does it preserve service stability?
Severity classification — respond fast, escalate faster
Sev 1 (Critical): Complete outage or data loss risk. War-room bridge opened within 15 min. Executive notification within 30 min. All hands until resolved.
Sev 2 (High): Major degradation, partial service available. Senior resolver engaged within 30 min. Business workaround communicated within 1 hour.
Sev 3 (Medium): Moderate impact, workaround available. Resolved within agreed business-day SLA.
Sev 4 (Low): Minor inconvenience, single user or cosmetic issue. Queued and resolved within standard SLA.
- Incident vs Problem: Incidents restore service — fast. Problems find root cause — thoroughly. A Sev 1 bridge is not an RCA; it is a restoration exercise. RCA happens in a separate Problem record once service is restored.
- Communication is non-negotiable: During any Sev 1 or Sev 2, a named Communications Lead must provide status updates at fixed intervals (every 30 min for Sev 1). Silence breeds distrust.
- KEDB discipline: Every resolved Problem must have its workaround and root cause recorded in the Known Error Database before the Problem record is closed.
- Change freeze windows: Operations defines blackout periods (financial year-end, peak trading) during which no non-emergency changes may be deployed. Transition must respect these without exception.
- Proactive monitoring: A well-tuned monitoring platform that raises a Warning event before degradation occurs is worth more than any number of skilled incident responders.
Stability is not the enemy of innovation — it is its foundation.
Gate → Accepted into BAU (exit Early Life Support) · all must be approved
- Service stable through Early Life Support; SLAs being met.
- Incident, Problem & Request Fulfilment processes live; KEDB populated.
- Monitoring & alerting tuned and proven in production.
- Support model, on-call rota and escalation paths confirmed.
- Outstanding go-live defects closed, or formally accepted with owners and dates.
Who opens the gate: the Service Owner formally accepts the service into business-as-usual.
CSI
Always On
CSI is not a phase — it is a permanent discipline. While the other four phases are sequential, CSI runs continuously and feeds improvement intelligence back into all of them simultaneously.
Every complaint, every SLA breach, every Sev 1, every failed UAT, and every piece of user feedback is an improvement signal. The CSI Register is where those signals are captured, prioritised, and tracked to resolution.
The Deming discipline
Plan something. Do it. Check whether it worked. Act on what you find. Then repeat — permanently. CSI without measurement is just opinion. Establish a baseline first, then measure improvement against it.
- Own it by Business Function: In ITIL 4 and beyond, CSI Registers are most effective when owned by a Business Function's Product Owner — accountable for both service quality and the backlog of improvements driving it.
- Measure what matters: Service metrics (did we hit the SLA?), Process metrics (is the process efficient?), Technology metrics (is the infrastructure healthy?). Report all three.
- Close the loop: Every improvement actioned must be followed by a measurement of whether it worked. Communicate the result to stakeholders — this builds credibility and appetite for further investment.
- SIP as the formal vehicle: Where CSI identifies a pattern of SLA failures, a formal Service Improvement Plan must be raised, resourced, and tracked to completion.
Organisations that treat CSI as optional achieve average service quality. Those that embed it as a cultural habit consistently outperform their peers.
Gate per improvement · all must be in place
- Baseline established before any change is claimed as an improvement.
- Improvement logged in the CSI Register / backlog and ranked by the Product Owner.
- A formal SIP raised where SLA failures form a pattern.
- Benefit re-measured after the change and reported to stakeholders.
Who opens the gate: the Business-Function Product Owner, accountable for the ranked improvement backlog that feeds all four phases.
Service Strategy
Scrum Backlog = CSI Register & Pipeline
The Product Backlog is the Scrum equivalent of the ITIL Service Portfolio Pipeline and the CSI Register combined.
- The Product Owner owns and manages the backlog — they are the Business Function authority accountable for value.
- Once the Charter is signed, the Product Owner formally grooms the backlog — refining, prioritising, and sizing user stories before Sprint Planning.
- Each backlog item represents a business need or improvement — not a technical task.
Effort sizing at this stage:
Stories are rough-sized using 8 or 13 points. Anything that can't be estimated is an Epic — split it before Sprint Planning.
Definition of Ready · before a story enters Sprint Planning
- Clear business value & acceptance criteria written.
- Sized in story points — not still an Epic.
- Ranked by the Product Owner against the rest of the backlog.
- Dependencies & risks identified.
Gate-keeper: the Product Owner — only Ready, ranked items are pulled, however long the backlog.
Service Design
Sprint Planning
Sprint Planning is where Service Design thinking happens in Scrum — the team selects backlog items and commits to delivering them within the sprint.
- The team breaks selected stories into sprint tasks, confirms acceptance criteria, and agrees the Definition of Done (DoD).
- Story points refined here: 1 3 5 point stories are sprint-ready; 8 point stories need careful scoping.
- Capacity, availability, and dependencies confirmed — mirroring ITIL's Availability & Capacity Management.
Design the DoD, not just the feature:
The Definition of Done must include testing criteria, code review, and documentation — not just "it works on my machine."
Must be in place to commit the Sprint
- Sprint Goal agreed.
- Selected stories meet the Definition of Ready.
- Team capacity calculated for the sprint.
- Definition of Done agreed (tests, review, docs).
- Acceptance criteria confirmed per story.
Gate-keeper: the whole Scrum Team commits; the Product Owner confirms priority.
Service Transition
Sprint Review → UAT → CI/CD
Done stories are demonstrated to the Product Owner at the Sprint Review — this is the ITIL Service Validation gate.
- The Product Owner confirms each story meets its acceptance criteria — equivalent to formal UAT sign-off.
- Rejected stories return to the backlog with clear feedback — they are not Done.
- CI/CD pipelines handle ITIL's Release & Deployment — automated, repeatable, with a rollback path.
- Knowledge articles and runbooks updated before merge to main — not after go-live.
The Sprint Review is not a demo — it is a gate:
Only stories that pass Product Owner acceptance are marked Done. Partial work is not Done.
Definition of Done · before a story is accepted
- Code peer-reviewed and merged.
- Automated tests green in CI.
- PO accepts against acceptance criteria at Sprint Review.
- Runbooks / knowledge articles updated.
- Deployable through CI/CD with a rollback path.
Gate-keeper: the Product Owner accepts or rejects each story — rejected work returns to the backlog.
Service Operations
"Done Done" — Live in Production
Done Done means the feature is live, stable, and operating within agreed SLAs. It has passed UAT and survived production.
- The Scrum Team monitors the release post-deployment — incidents raised via the ITIL Incident process.
- A Sprint Retrospective runs alongside — identifying what worked and what needs improving.
- Stability rules here: no scope additions, no unplanned changes outside the change process.
Velocity is earned here:
Story points only count toward team velocity when a story is Done Done — live in production with no critical defects open.
Required for "Done Done" · counts toward velocity
- Live in production and stable.
- No critical / Sev-1 defects open.
- Operating within agreed SLAs and monitored.
- Incident process wired to the on-call team.
Gate-keeper: production telemetry + the Service Owner — not opinion.
CSI
Production Issues → Backlog
CSI is the feedback loop. Issues discovered after go-live — defects, SLA breaches, user feedback, monitoring alerts — flow back into the Product Backlog as CSI items.
- The Product Owner triages and prioritises CSI items alongside new features — nothing enters a sprint without backlog grooming.
- Bugs from production are raised as Problem records in ITIL terms; the RCA outcome becomes a backlog story.
- The Retrospective also feeds CSI — process improvements are captured and tracked.
Close the loop every sprint:
At least one CSI item should be in every sprint. A team that never improves its process is accumulating technical and operational debt.
Must be in place every sprint
- At least one CSI / improvement item committed in the sprint.
- Production issues raised as Problem records → backlog stories.
- Retrospective actions owned, dated and tracked.
- Improvement benefit re-measured the following sprint.
Gate-keeper: the Scrum Master ensures actions are tracked; the Product Owner ranks them into the backlog.