Sprint: Arbeitszyklus mit klaren Verantwortlichkeiten und prüfbarem Ergebnis

Ein Sprint ist im Scrum-Framework ein Zeitraum fester Länge von höchstens einem Monat, in dem ein Team ein vereinbartes Sprint-Ziel verfolgt und ein Inkrement erstellt, das die gemeinsam festgelegten Qualitätskriterien erfüllt. Der Scrum Guide 2020 verknüpft jeden Sprint mit festen Verbindlichkeiten. Wer über den Inhalt entscheidet, wer umsetzt und wann ein Ergebnis als fertig gilt, ist damit geregelt.

Was Scrum nicht regelt, ist der Weg in die Produktion. Für Banken, Versicherungen, Spitäler oder die öffentliche Verwaltung stellt sich deshalb weniger die Frage, ob agile Teams zulässig sind. Entscheidend ist, wie ihre Ergebnisse geprüft, freigegeben und nachvollziehbar in Betrieb gehen. Dafür braucht es neben dem Sprint ein kontrolliertes Change- und Release-Management.

Das Wichtigste in Kürze

• Fester Rahmen: Höchstens ein Monat, gleichbleibende Länge, ein Sprint-Ziel. Vier Events mit festen Höchstdauern strukturieren den Ablauf.
• Klare Zuständigkeiten: Der Product Owner ordnet die Arbeit und kann als Einziger einen Sprint abbrechen. Die Developer entscheiden über die Umsetzung.
• Qualitätsschwelle: Die Definition of Done legt fest, wann ein Ergebnis fertig ist. Sie kann als Unternehmensstandard für alle Teams verbindlich gemacht werden.
• Keine automatische Freigabe: Ein fertiges Inkrement ist noch keine genehmigte Änderung. Von Banken und Wertpapierhäusern verlangt das FINMA-Rundschreiben 2023/1 ein Änderungsmanagement mit Verfahren, Prozessen und Kontrollen.
• Nachweise im Prozess: Belege entstehen am zuverlässigsten dort, wo gearbeitet wird: im Ticket, im Change und in dessen Historie.

Stand: November 2026 · Fachlich abgeglichen mit dem Scrum Guide 2020, dem FINMA-Rundschreiben 2023/1, dem DSG auf Fedlex und ITIL 4 (Quellen am Ende des Artikels)

Was ein Sprint verbindlich festlegt

Der Scrum Guide beschreibt Scrum bewusst als unvollständiges Rahmenwerk, das eigene Praktiken zulässt. Einige Elemente sind aber nicht verhandelbar. Sie eignen sich als Ansatzpunkte für Governance und interne Kontrolle.

Drei Verantwortlichkeiten

• Product Owner: verantwortet den Wert des Produkts und das Product Backlog. Nur der Product Owner kann einen Sprint abbrechen, und nur dann, wenn das Sprint-Ziel hinfällig geworden ist.
• Developer: planen, wie die ausgewählten Einträge umgesetzt werden, und sind an die Definition of Done gebunden. Wie sie die Arbeit erledigen, entscheiden sie selbst.
• Scrum Master: verantwortet, dass Scrum wie im Scrum Guide beschrieben eingeführt wird, und die Wirksamkeit des Teams.

Drei Verpflichtungen

• Produkt-Ziel für das Product Backlog: der angestrebte künftige Zustand des Produkts.
• Sprint-Ziel für das Sprint Backlog: das eine Ziel des Sprints, festgelegt im Sprint Planning.
• Definition of Done für das Inkrement: die formale Beschreibung, wann ein Ergebnis die geforderten Qualitätskriterien erfüllt. Ein Eintrag, der sie nicht erfüllt, darf weder ausgeliefert noch im Sprint Review gezeigt werden.

Regeln während des Sprints

Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden, und die Qualität nimmt nicht ab. Der Umfang kann mit dem Product Owner neu verhandelt werden. Die Events haben feste Höchstdauern, bezogen auf einen Monats-Sprint: Sprint Planning acht Stunden, Daily Scrum 15 Minuten, Sprint Review vier Stunden, Retrospektive drei Stunden.

Für die Kontrolle ist die Definition of Done besonders wertvoll. Ist sie Teil der Unternehmensstandards, müssen alle Scrum-Teams sie mindestens einhalten. So lassen sich Mindestanforderungen an Tests, Sicherheitsprüfungen und Dokumentation verbindlich verankern, ohne jedem Team seine Arbeitsweise vorzuschreiben. Mehr zum Rahmenwerk im Glossarartikel Scrum.

Sprint, Release und Change: drei getrennte Entscheidungen

In agilen Organisationen verschwimmen diese Begriffe leicht. Für die interne Kontrolle ist die Trennung wesentlich, weil hinter jedem Begriff eine andere Entscheidung und eine andere Verantwortung steht:

Nach dem Scrum Guide darf ein Inkrement schon vor dem Ende des Sprints ausgeliefert werden. Das Sprint Review ist ausdrücklich kein Freigabetor. Gerade deshalb muss die Freigabe für die Produktion an anderer Stelle geregelt sein. ITIL 4 behandelt sie in der Practice Change Enablement: Änderungen werden auf ihr Risiko bewertet und von einer zuständigen Change Authority autorisiert. Risikoarme, wiederkehrende Änderungen lassen sich als Standard-Change vorab genehmigen. Das passt zu Teams, die häufig ausliefern (siehe Change Management und Change Advisory Board).

Funktionstrennung im selbstmanagenden Team

Selbstmanagement bedeutet im Scrum Guide 2020, dass das Team intern entscheidet, wer was wann und wie erledigt. Kontrollen, die von ausserhalb des Teams verlangt werden, hebt es nicht auf. Wer eine Änderung umsetzt, sollte sie nicht allein für die Produktion freigeben. Das Vier-Augen-Prinzip lässt sich im Team abbilden, etwa durch eine Prüfung der Änderung durch eine zweite Person, oder ausserhalb des Teams durch die Change Authority.

Sprints in regulierten Umgebungen: Nachweise ohne Zusatzschleifen

Was die FINMA verlangt

Das FINMA-Rundschreiben 2023/1 «Operationelle Risiken und Resilienz – Banken» gilt seit dem 1. Januar 2024 für Banken, Wertpapierhäuser sowie Finanzgruppen und Finanzkonglomerate. Für das Änderungsmanagement verlangt es in den Randziffern 50 bis 52 Verfahren, Prozesse und Kontrollen für alle Phasen der Entwicklung oder Beschaffung von IKT, eine Berücksichtigung der Auswirkungen auf die IKT-Risiken in jeder Phase und die Trennung der Entwicklungs- und Testumgebungen von der Produktion. Funktionale und nicht-funktionale Anforderungen sind klar zu definieren, zu genehmigen und nach ihrer Kritikalität zu testen. Kleinere Institute der FINMA-Kategorien 4 und 5 sind von einzelnen dieser Randziffern ausgenommen. Eine bestimmte Entwicklungsmethode schreibt das Rundschreiben nicht vor. Sprints sind damit vereinbar, wenn der Weg vom Inkrement in die Produktion diese Anforderungen erfüllt. Für andere Branchen ist das Rundschreiben nicht verbindlich, kann aber als Orientierung dienen.

Datenschutz ab dem ersten Sprint

Art. 7 des Datenschutzgesetzes (DSG, SR 235.1) verpflichtet Verantwortliche, die Datenbearbeitung technisch und organisatorisch so auszugestalten, dass die Datenschutzvorschriften eingehalten werden, und zwar ab der Planung. Für Sprints heisst das: Datenschutzfragen gehören in die Verfeinerung des Backlogs und in die Definition of Done, nicht in eine Prüfung kurz vor dem Livegang. Art. 8 DSG verlangt zudem eine dem Risiko angemessene Datensicherheit.

Ein Beispiel

Angenommen, eine Privatbank in Zürich entwickelt ihr Kundenportal in Zwei-Wochen-Sprints. Sie legt eine unternehmensweite Definition of Done fest: Prüfung des Codes durch eine zweite Person, automatisierte Tests, Sicherheitsprüfung, Datenschutzcheck bei neuen Datenfeldern und aktualisierte Betriebsdokumentation. Jedes Inkrement, das in die Produktion soll, erhält einen Change. Wiederkehrende, risikoarme Auslieferungen sind als Standard-Change vorab genehmigt. Neue Funktionen, die Kundendaten verarbeiten, gehen über die Change Authority. Prüft die interne Revision später, findet sie zu jeder produktiven Änderung den Change mit Bewertung, Freigabe und Testnachweis, ohne dass das Team dafür eigene Berichte schreiben musste.

Was ky2help^® beiträgt

Change Enablement und Release Management gehören zu den 13 Practices, für die ky2help^® von PeopleCert nach ITIL^® 4 akkreditiert ist. Automatische Historisierung und ein integriertes Daten-Audit unterstützen eine revisionssichere Dokumentation. Genehmigungsschritte passen Sie im Prozessdesigner per Drag-and-Drop an. ky2help^® läuft als SaaS mit eigener Instanz in einem Rechenzentrum in der Schweiz oder in Deutschland oder On-Premises in Ihrer eigenen Infrastruktur. Mehr für Finanzinstitute auf der Seite Finanzdienstleistungen und Banken.

Funktionsumfang prüfen

Risiken und Kontrollen nach Priorität

Die folgenden Punkte sind nach ihrer Bedeutung für Revision und Aufsicht geordnet:

1. Auslieferungen ohne Change: Ein Team spielt ein Inkrement direkt ein, weil «der Sprint ja fertig ist». Kontrolle: Jede produktive Änderung ist mit einem Change verknüpft, Routineauslieferungen laufen als vorab genehmigter Standard-Change.
2. Schwache Definition of Done: Tests, Sicherheits- oder Datenschutzprüfungen fehlen oder sind von Team zu Team verschieden. Kontrolle: eine unternehmensweite Mindestfassung, die alle Teams einhalten.
3. Fehlende Trennung der Umgebungen: Entwicklung, Test und Produktion laufen auf denselben Systemen oder mit denselben Berechtigungen. Kontrolle: getrennte Umgebungen mit klar zugewiesenen Zugriffsrechten.
4. Notfallkorrekturen am Prozess vorbei: Ein dringender Fix wird ohne Dokumentation eingespielt. Kontrolle: ein Notfall-Change mit verkürzter Freigabe durch eine vorab bestimmte Stelle und zeitnaher Nachdokumentation.
5. Zeitdruck zulasten der Qualität: Am Sprint-Ende werden Prüfungen übersprungen. Kontrolle: Die Regel des Scrum Guide, dass die Qualität nicht abnimmt, wird in der Retrospektive überprüft. Sprint-Kennzahlen dienen nicht als Leistungsvorgabe für einzelne Personen.
6. Daten in ungeklärten Werkzeugen: Backlog-Einträge oder Testdaten enthalten Personendaten und liegen in Tools mit unklarer Datenhaltung. Kontrolle: Testdaten anonymisieren, Werkzeuge mit geklärtem Speicherort einsetzen und bei einer Bekanntgabe ins Ausland Art. 16 DSG beachten.

Fragen, auf die ein Team vorbereitet sein sollte

• Wer hat diese Änderung für die Produktion freigegeben, und wann?
• Welche Tests und Prüfungen liefen vor der Auslieferung?
• Welche Definition of Done galt zum Zeitpunkt der Umsetzung?
• Wie wurden Datenschutz und Datensicherheit berücksichtigt?

Lassen sich diese Fragen aus dem Ticket- und Change-Verlauf beantworten, ist der Sprint kein Risiko für die Prüfbarkeit, sondern ein gut dokumentierter Arbeitsschritt.

Häufige Fragen zum Sprint

Was ist ein Sprint?

Ein Sprint ist im Scrum-Framework ein Zeitraum fester Länge von höchstens einem Monat. In dieser Zeit verfolgt ein Team ein Sprint-Ziel und erstellt ein Ergebnis, das die Definition of Done erfüllt. Planung, tägliche Abstimmung, Review und Retrospektive finden innerhalb des Sprints statt.

Sind Sprints mit den Anforderungen der FINMA vereinbar?

Das FINMA-Rundschreiben 2023/1 schreibt keine Entwicklungsmethode vor. Es verlangt von Banken und Wertpapierhäusern ein Änderungsmanagement mit Verfahren, Prozessen und Kontrollen sowie die Trennung der Entwicklungs- und Testumgebungen von der Produktion. Sprints sind vereinbar, wenn der Weg in die Produktion diese Anforderungen erfüllt.

Wer gibt das Ergebnis eines Sprints für die Produktion frei?

Nicht das Sprint Review, es ist ausdrücklich kein Freigabetor. Die Freigabe erfolgt über das Change Enablement: Eine zuständige Change Authority bewertet und autorisiert die Änderung, oder die Änderung fällt unter einen vorab genehmigten Standard-Change.

Was gehört in eine Definition of Done für regulierte Umgebungen?

Typische Punkte sind eine Prüfung durch eine zweite Person, automatisierte Tests, Sicherheitsprüfungen, ein Datenschutzcheck bei neuen Personendaten und aktualisierte Betriebsdokumentation. Als Unternehmensstandard gilt sie für alle Scrum-Teams als Mindestanforderung.

Wer darf einen Sprint abbrechen?

Nur der Product Owner, und nur wenn das Sprint-Ziel hinfällig geworden ist. Für die Nachvollziehbarkeit empfiehlt es sich, Grund und Entscheid des Abbruchs festzuhalten.

Wo werden die Daten von ky2help® gespeichert?

ky2help® lässt sich als SaaS mit eigener Instanz in einem Rechenzentrum in der Schweiz oder in Deutschland betreiben oder On-Premises in der eigenen Infrastruktur. Welche Variante passt, klären wir gern in einem Beratungsgespräch.

Quellen und weiterführende Artikel

Quellen

• Ken Schwaber, Jeff Sutherland: The 2020 Scrum Guide (englisch) und deutsche Fassung (PDF)
• FINMA: Rundschreiben 2023/1 «Operationelle Risiken und Resilienz – Banken» (PDF)
• Fedlex: Bundesgesetz über den Datenschutz (DSG), SR 235.1
• AXELOS/PeopleCert: ITIL 4 Practice Guide Change Enablement
• PeopleCert: ITIL 4 Practitioner: Change Enablement

Weiterlesen im Glossar und auf kyberna.ch

• Change Management und Change Advisory Board
• ISO 27001 und Scrum
• Was ist ITIL Release Management? und Backlog
• ky2help® für Finanzdienstleistungen und Banken und Referenz Personalamt Kanton Thurgau