Scrum für ServiceNow-Projekte

⚖️ Klassische Entwicklung vs. ServiceNow

Aspekt	Klassische Entwicklung	ServiceNow Projekt
Haupttätigkeit	Code schreiben (Java, Python, JS...)	Konfiguration & Low-Code (Flow Designer, Workflows)
Versionskontrolle	Git (Branches, Commits, Merges)	Update Sets, App Repository
Deployment	CI/CD Pipeline (Jenkins, GitLab CI...)	Update Set Migration (DEV → TEST → PROD)
Testing	JUnit, Jest, Selenium...	ATF (Automated Test Framework)
Architektur	Eigenes Design (Microservices, Monolith...)
Scripting	100% Custom Code	~20% Scripts, ~80% Konfiguration
SOLID / Clean Code	Essentiell	Nur für Script Includes relevant

🚀 ServiceNow Deployment-Pipeline

Update Set Promotion (statt klassischem CI/CD)

DEV Instance

Entwicklung & Konfiguration

Update Set

→

TEST Instance

ATF Tests & UAT

Update Set

→

PROD Instance

Go-Live

📦 Update Sets = Die ServiceNow Version von "Commits"

• Jede Änderung wird in einem Update Set erfasst
• Update Sets können zwischen Instances migriert werden
• Best Practice: Ein Update Set pro User Story / Feature
• Batch Parent für Sprint-Release (bündelt alle Sprint Update Sets)

📅 Scrum Events angepasst für ServiceNow

📋

Sprint Planning

Max. 8h für 4-Wochen Sprint

ServiceNow-spezifisch:

Welche Prozesse/Module diesen Sprint?
Konfiguration vs. Customization klären
Abhängigkeiten zu anderen Modulen?
Update Set Strategie festlegen

☀️

Daily Scrum

15 Minuten, jeden Tag

ServiceNow-spezifisch:

Update Set Konflikte besprechen
Wer arbeitet in welchem Modul?
Instance-Probleme (Performance, Bugs)?
Blocker: Fehlende Berechtigungen?

🎯

Sprint Review

Max. 4h für 4-Wochen Sprint

ServiceNow-spezifisch:

Live-Demo auf TEST Instance
Prozess-Walkthrough mit Stakeholdern
Feedback zu Formularen, Workflows
Go/No-Go für PROD Deployment?

🔄

Sprint Retrospective

Max. 3h für 4-Wochen Sprint

ServiceNow-spezifisch:

Update Set Management verbessern?
Zu viel Customization vs. Config?
ATF Test Coverage erhöhen?
Dokumentation ausreichend?

📦 Scrum Artefakte im ServiceNow-Kontext

📜

Product Backlog

Commitment: Product Goal

ServiceNow: Alle zu implementierenden Prozesse, Module, Integrationen (z.B. ITSM, CSM, ITOM...)

📝

Sprint Backlog

Commitment: Sprint Goal

ServiceNow: User Stories für diesen Sprint (z.B. "Incident Management Workflow konfigurieren")

🎁

Increment

Commitment: Definition of Done

ServiceNow: Funktionierender, getesteter Prozess auf TEST Instance, bereit für UAT/PROD

✅ Definition of Done für ServiceNow

📋 Beispiel DoD für ServiceNow-Projekte

🔧 Konfiguration

☑Workflow/Flow funktioniert wie spezifiziert

☑Formulare vollständig konfiguriert

☑Berechtigungen (ACLs) gesetzt

☑Notifications konfiguriert

🧪 Testing

☑ATF Tests erstellt und bestanden

☑Happy Path manuell getestet

☑Edge Cases geprüft

☑Keine Fehler in System Logs

📦 Deployment

☑Update Set vollständig

☑Keine Update Set Konflikte

☑Migration auf TEST erfolgreich

☑Peer Review durchgeführt

📚 Dokumentation

☑Technische Dokumentation aktualisiert

☑Prozess-Dokumentation erstellt

☑Known Issues dokumentiert

☑Release Notes geschrieben

🔄 PSD I Themen übersetzt für ServiceNow

PSD I Thema	ServiceNow Äquivalent	Relevanz
TDD (Test-Driven Development)	ATF Tests vor Konfiguration planen, Acceptance Criteria als ATF definieren	⚠️
CI/CD Pipeline	Update Set Promotion, Batch Parents, Deployment Gates zwischen Instances	⚠️
Git / Version Control	Update Sets, Source Control Integration (optional), App Repository	⚠️
Unit Tests	ATF Server/Client Tests, Script Includes testen	⚠️
SOLID Principles	Relevant nur für Script Includes, Business Rules mit viel Code	❌
Refactoring	Workflow-Optimierung, Prozess-Vereinfachung, Script-Bereinigung	✅
Technical Debt	Customization statt Config, veraltete Workflows, fehlende Tests	✅
Code Reviews	Update Set Reviews, Script Reviews, Configuration Reviews	✅
Emergent Architecture	Iterative Prozess-Entwicklung, Modul für Modul, nicht Big Bang	✅

✅ Fazit zur PSD I Relevanz

Die PSD I Zertifizierung ist wertvoll für das Verständnis von Development Best Practices und Scrum aus Developer-Sicht. Für ServiceNow-Projekte ist jedoch PSM I relevanter, da der Fokus auf Prozess-Konfiguration liegt, nicht auf klassischer Softwareentwicklung.

💡 Best Practices für Scrum + ServiceNow

1 Config vor Custom: Prüfe immer zuerst Out-of-Box Möglichkeiten bevor Custom Scripts geschrieben werden. Technical Debt vermeiden!
2 Ein Update Set pro Story: Erleichtert Rollbacks und macht Änderungen nachvollziehbar. Batch Parent für Sprint-Release.
3 Demo auf TEST, nicht DEV: Sprint Reviews immer auf TEST Instance durchführen - näher an PROD, realistischere Demo.
4 ATF von Anfang an: Automated Test Framework Tests parallel zur Konfiguration erstellen, nicht erst am Ende.
5 Prozess-Owner einbinden: Fachbereich bei Refinement und Sprint Review dabei - sie kennen die echten Anforderungen.
6 Naming Conventions: Update Sets, Scripts, Workflows einheitlich benennen (z.B. "SPRINT-12_INC_Workflow_Approval").
7 Instance Strategy klären: Wann wird gecloned? Wer arbeitet wo? Wie werden Konflikte gelöst? VOR Sprint 1 klären!
8 Keine Parallel-Arbeit am selben Record: Update Set Konflikte vermeiden - Daily Scrum nutzen um Überschneidungen zu koordinieren.

👑 Wann braucht ihr PRINCE2 Agile zusätzlich?

✅

PRINCE2 Agile empfohlen

Externes Budget & feste Meilensteine
Steering Committee / Lenkungsausschuss
Mehrere Lieferanten / Vendors beteiligt
Compliance / Audit-Anforderungen
Projekt > 6 Monate
Go-Live Datum ist fix

🏃

Scrum alleine reicht

Internes Projekt ohne externe Stakeholder
Flexibles Budget (Time & Material)
Ein Team, ein Produkt
Scope kann flexibel priorisiert werden
Projekt < 6 Monate
Wenig formale Governance nötig

💡 Empfehlung für euer ServiceNow-Projekt

Nutzt das hybride Modell: PRINCE2 Agile für die Projekt-Governance (Budget, Verträge, Meilensteine, Go-Live) und Scrum für die Sprint-Arbeit (Konfiguration, Testing, Demos). So bekommt ihr das Beste aus beiden Welten!