Scrum Framework
The Sprint Lifecycle
Scrum operates through time-boxed iterations called sprints (up to 4 weeks). Each sprint moves through four ceremonies, delivering a potentially releasable product increment.
Key principle: Scrum is not a methodology — it is a framework. It provides structure for continuous improvement through empirical process control: transparency, inspection, and adaptation.
Step 1 · Start of Sprint
🗓️
Sprint Planning
The entire Scrum team collaborates on the highest-priority backlog items and defines the sprint goal. The Development Team has the final say on scope.
~4 hrs / 2-week sprint
All roles attend
Step 2 · Daily
☀️
Daily Scrum
15-minute daily sync for the Development Team to inspect progress toward the sprint goal. Not a status meeting — an opportunity to adapt daily.
15 min max
Dev team
Step 3 · End of Sprint
🔍
Sprint Review
The team demonstrates the working increment to stakeholders. The product backlog is adapted based on feedback. Product Owner may release completed functionality.
Product-focused
Stakeholders invited
Step 4 · End of Sprint
🔄
Sprint Retrospective
The team reflects on its process, tools, and relationships. Actionable improvements are identified for the next sprint. Process-focused — not product-focused.
Process-focused
Continuous improvement
Scrum Roles
Role 1
👤
Product Owner
Vision, backlog, priorities
Accountable for value
Product Owner
Defines and prioritises the product backlog. Owns the product vision. Answers execution and acceptance questions during sprint planning. Has authority to release completed features.
Role 2
🧭
Scrum Master
Coach, facilitator, shield
Servant leader
Scrum Master
Facilitates all Scrum ceremonies. Holds the team accountable to Scrum values and working agreements. Removes impediments and protects the team from external disruption.
Role 3
🛠️
Development Team
Build, self-organise, deliver
Accountable for delivery
Development Team
Cross-functional, self-organising team that creates the product. They decide how to accomplish the work. Completeness of work responsibility sits entirely with the team.
Scaled Agile
Scrum of Scrums
A first step to scaling agile — connects multiple Scrum teams working together to deliver complex solutions, reducing communication paths through interlinking team structures.
Team size: 4–6 people per team. Teams that are too small or large struggle with delivery of complex products. Each team provides a delegate ambassador to the Scrum of Scrums team.
Layer 1
👥
Individual Scrum Teams
4–6 members, own backlog, self-organising
Delivery Teams
Standard Scrum teams running sprints independently. Each team has its own Product Owner, Scrum Master, and Development Team. Teams operate at full Scrum cadence.
- Independent sprint planning and retrospectives
- Own definition of done
- Self-organising delivery capability
Layer 2
🔗
Delegate Ambassadors
Embedded links between teams
Team Ambassadors
Each Scrum team nominates a delegate to represent them at the Scrum of Scrums ceremony. The delegate communicates team status, blockers, and integration needs.
- Communicates work completed since last meeting
- Surfaces integration blockers
- Flags dependencies between teams
Layer 3
🏛️
Scrum of Scrums Team
Coordinates, integrates, unblocks
Coordination Layer
The ambassadors form the Scrum of Scrums team, applying Scrum practices to coordinate at scale. May include additional roles such as architects or QA leaders to support integration.
- Ensures team outputs integrate correctly
- Removes cross-team impediments
- Coordinates delivery of complex features
- May add architecture/QA oversight roles
Output
🚀
Integrated Product
Potentially shippable each sprint
Sprint Output
The goal is a single integrated, potentially shippable product increment at the end of every sprint — even when multiple teams contributed different parts of the solution.
Platform Team Concept
Platform Team Strategy: When multiple teams work on organisation-wide features, a dedicated platform team should be established in parallel. Based on Google's Site Reliability Engineering (SRE) model — centralises management of shared components, automates operations (CI/CD), and manages incidents, problems, changes, and deployments at platform level.
Scaled Agile Framework
SAFe 6.0 Configuration Levels
SAFe scales lean and agile practices across the enterprise. Four configurations address organisations from small to extremely large. Core values: alignment, built-in quality, transparency, and programme execution.
🏃
Team Level
Individual agile teams running sprints. Roles: Product Owner and Scrum Master. Powers the Agile Release Train (ART) as the fundamental delivery unit.
Product Owner
Scrum Master
Development Team
Team Level Detail
The foundation of SAFe. All SAFe agile teams run 2-week iterations, participate in PI Planning, and contribute to the ART's integrated programme increment. Teams use story points, velocity, and team backlogs.
- Sprint planning, review, retrospective, daily stand-up
- Team backlog managed by Product Owner
- 2-week sprint cadence aligned to PI
🚂
Programme Level (Essential SAFe)
Agile Release Train (ART) — a long-lived team of 50–125 people delivering value on a regular cadence. PI Planning is the heartbeat of the ART.
Release Train Engineer
Systems Architect
PI Planning
System Demo
Programme Level Detail
The ART is the primary value delivery mechanism. A Programme Increment (PI) is 8–12 weeks of work. Key ceremonies include PI Planning, System Demo, and Inspect & Adapt.
- PI Planning — cadence-based, aligns all teams on mission and vision
- System Demo — integrated feature view each iteration
- Inspect & Adapt — end-of-PI evaluation and problem solving
- Release Train Engineer = Scrum Master at ART level
🏗️
Large Solution Level
Co-ordinates multiple ARTs and suppliers on a solution train. Used when a single ART cannot deliver the full solution. Adds solution-level roles and ceremonies.
Solution Manager
Solution Architect
Pre/Post-PI Planning
Solution Demo
Large Solution Detail
Adds pre- and post-PI planning events to prepare and follow up after PI planning for ARTs and suppliers. Solution Demo integrates outputs from all ARTs for stakeholder evaluation.
- Solution Manager prioritises capabilities
- Solution Architect/Engineer owns cross-ART architectural vision
- Solution Demo replaces System Demo at this level
💼
Portfolio Level (Full SAFe)
Strategic direction, investment funding, and lean governance. Epics are defined here. Enterprise Architect drives portfolio-wide architectural initiatives.
Epic Owners
Enterprise Architect
Strategic Portfolio Review
Quarterly cadence
Portfolio Level Detail
Connects strategy to execution. Epics are significant development investments. Strategic Portfolio Review held quarterly for budget alignment and portfolio vision advancement.
- Epics → Features → Stories (decomposition hierarchy)
- Enterprise Architect drives cross-portfolio innovation
- Lean portfolio management and governance
- Strategic portfolio review on quarterly cadence
Framework Comparison
| Framework |
Best For |
Team Size |
Complexity |
| Scrum |
Single team, fast iteration, well-scoped work |
5–9 people |
Low |
| Scrum of Scrums |
Multiple teams, first step to scaling |
3–5 teams |
Medium |
| SAFe |
Large enterprise, hundreds of people, complex solutions |
50–1000+ |
High |
| Hybrid (Now Create) |
ServiceNow delivery — structured initiation + agile execution |
Any |
Medium |
Data Modelling
CMDB–CSDM Alignment Process
A structured 5-stage approach to aligning the Configuration Management Database with the Common Service Data Model. As a CTA, you lead this process. Click each stage for detail.
Stage 1
📋
Prepare
Approach, resources, legacy mapping
Foundation
Prepare Stage
Determine implementation approach: service-focused or application (IT)-focused. Ensure alignment with prior efforts if this is a legacy deployment.
- Assign Enterprise Architect, CMDB Manager, Process Owners
- Identify ServiceNow Product Owner and Developer/Admin
- Map and migrate legacy lifecycle values to CSDM standards
- Enable required plugins for the transition
Stage 2
📊
Gather Data
Business apps, services, health scan
Discovery
Gather Data Stage
Collect data based on your chosen approach. For legacy deployments, run a CMDB Health Scan first.
- App-focused: List all business applications and production installs
- Service-focused: List services + supporting applications for Day 1 readiness
- Run CMDB Health Scan to assess data quality and issues
- Use scripts to evaluate impact of data remediation
Stage 3
🗺️
Model Data
Workbooks, diagrams, governance
Architecture
Model Data Stage
Define data structures and visualise relationships based on your approach.
- App-focused: Use Data Modelling Workbook + data diagrams
- Service-focused: Provide Service Taxonomy, use Service Builder
- Relate services to supporting applications
- Develop governance processes for long-term sustainability
Stage 4
📥
Enter Data
Import sets, transform maps, manual entry
Data Loading
Enter Data Stage
Load CSDM-related data into ServiceNow using import sets and transform maps. Manual entry for cases requiring individual validation.
- Import: Business Applications, Application Services, Business Services
- Import: Technical Services, Service Offerings, relationship data
- Key relationships: Consumes, Contains, Depends On
- Review and test data entry processes for accuracy and completeness
Stage 5
⚙️
Maintain / Use
Governance, reporting, training
Ongoing
Maintain / Use Data Stage
Shift focus to ongoing data quality, governance, and operational integration. Train data owners and users.
- Use CMDB Health Dashboard, Data Foundations, CMDB Workspace
- Use Data Manager for bulk lifecycle operations
- Create operational reports and dashboards
- Train users on data selection, maintenance, and lifecycle management
- Manage data retirement and creation processes
CTA Responsibility: As the Certified Technical Architect, you are expected to take a lead role in the CMDB–CSDM alignment process — pulling together Enterprise Architects, CMDB Managers, Process Owners, and ServiceNow Product Owners across the organisation.
CMDB Health
Three Pillars of CMDB Success
ServiceNow defines three pillars to success for operationalising the CMDB. All three must be healthy for the CMDB to provide real decision-support value.
01
📡
Ingestion
Populating the CMDB and keeping it current. Automated tools continuously bring in data and place it in the correct tables.
02
🛡️
Governance
Maintaining CMDB health after data ingestion. Focuses on completeness, correctness, and compliance of data.
03
💡
Insight
Realising value from a healthy CMDB. Turning data into operational intelligence and decision support.
Health Dashboard KPIs
KPI 1
✅
Completeness
Recommended + Required fields populated
Completeness
Measures whether CI records have the expected attributes populated. Sub-metrics: Recommended and Required field population rates.
KPI 2
🎯
Correctness
Staleness · Orphan · Duplicate CIs
Correctness
Measures data accuracy and currency. Three sub-metrics: stale CIs (not updated within threshold), orphan CIs (no relationships), and duplicate CIs (same entity recorded twice).
- IRE prevents duplicates at ingestion time
- Data Refresh Rules flag stale CIs by discovery source
- Duplicate CI Remediator merges and cleans duplicates
KPI 3
📏
Compliance
Audit rules adherence
Compliance
Measures whether CIs adhere to defined audit rules and governance policies. Expressed as percentage: healthy CIs / total CIs evaluated. Green = all metrics pass. Red = one or more failures.
CSDM
CSDM Maturity Journey
ServiceNow recommends a staged approach to CSDM implementation. Do not attempt all elements at once. Click each stage to see what data elements are recommended.
🏗️
Foundation
Critical referential data
✈️
Fly
Full CSDM alignment
Stage: Foundation
Foundation — Critical Referential Data
Tables in the Foundation domain contain base referential data required before any other ServiceNow product is used. This data is not part of CMDB relationships but is prerequisite to everything else.
- Company, department, location, and user records
- Assignment groups and support groups
- Categories and subcategories
- Roles and permissions baseline
Stage: Crawl
Crawl — Core ITSM CI Classes
Establish the fundamental CI classes needed to support core ITSM processes: Incident, Problem, and Change Management. Discovery is typically activated at this stage.
- Servers, network devices, storage (hardware CIs)
- Business Applications and Application Installs
- Basic CI relationships established by Discovery
- CMDB Health Dashboard activated
Stage: Walk
Walk — Service Mapping & Technical Services
Activate Service Mapping to create Application Services and understand technical dependencies. The Manage Technical Services domain becomes operational.
- Application Services (auto-discovered via Service Mapping)
- Technical Service offerings enabled
- CI dependency relationships mapped
- ITOM integration (Discovery + Service Mapping combined)
Stage: Run
Run — Business Services & Sell/Consume Domain
Connect technical services to the business. Business Services and Service Offerings are defined and linked to the Technical Services that support them.
- Business Services defined and mapped
- Business Service Offerings created
- Service Portfolio Management (SPM) integration
- Customer Service Management (CSM) integration
- Service Catalog aligned to service model
Stage: Fly
Fly — Full CSDM Alignment + AI Readiness
Complete CSDM alignment including the Build domain (SDLC components) and CSDM v5.0 AI-ready enhancements. Enterprise Architecture (EA) fully leverages the data model.
- Build domain: SDLC Components, DevOps integration
- CSDM v5.0: Ideate domain, SBOM support (CycloneDX)
- Design & Plan domain: business applications + platform hosts
- Service Instance base class (Deliver domain)
- Enterprise Architecture (EA) — full application portfolio visibility
- Automated governance via Data Manager policies
CSDM Domains
v4.0
🏛️
Foundation
Base referential data
Foundation Domain
Critical referential data referenced from all other domains. Required before any CMDB data is added. Not part of CMDB relationships directly.
v4.0
📐
Design
Business applications rationalisation
Design Domain
Represents tables to rationalise and manage business applications. Non-operational (cannot be selected for Incident or Change). Used by Enterprise Architecture (APM).
v4.0+
🔧
Build
SDLC components, DevOps
Build Domain
Added in CSDM v4.0. Includes Software Development Lifecycle Component (SDLC) class. In v5.0 adds SBOM support (CycloneDX). Direct target of Incident, Problem, and Change processes.
v4.0
⚙️
Manage Technical Services
Operational, ITOM, Discovery
Manage Technical Services Domain
Operational domain — selectable for Incident and Change. Used by ITOM (Service Mapping and Discovery). Represents technical services in use.
v4.0
🛒
Sell / Consume
Business services, SPM, CSM
Sell/Consume Domain
Business services that sell or consume technical services. Manages workflows and service-related data reporting. Used by Service Portfolio Management (SPM) and Customer Service Management (CSM).