Das Wichtigste in Kürze
- Klassisches Scrum wurde für Softwareentwicklung entworfen – nicht für Datenprojekte und KI.
- Feste Sprints, Velocity-Metriken und starre Sprint-Ziele stoßen bei Data-Science-Teams regelmäßig an strukturelle Grenzen.
- Data-Driven Scrum (DDS) ist ein Framework, das 2022 von Jeffrey Saltz (Syracuse University), Alex Sutherland (Scrum Inc.) und Nicholas Hotz (Indiana University) entwickelt wurde, um genau diese Lücke zu schließen.
- DDS ersetzt zeitbasierte Sprints durch ergebnisbasierte Iterationen: Erst wenn ein Experiment vollständig ausgewertet ist, beginnt das nächste.
- Das Framework integriert sich nahtlos in bestehende Scrum-Organisationen und baut gleichzeitig auf Kanban-Prinzipien auf.
- Für alle, die KI-Projekte steuern oder daran mitwirken, ist das Verständnis dieser Unterschiede eine Schlüsselkompetenz.
Viele Unternehmen starten KI-Projekte mit denselben agilen Methoden wie klassische Softwareprojekte. Nach kurzer Zeit zeigt sich jedoch: Trotz intensiver Arbeit bleiben die Sprint-Ziele unerreicht. Nicht weil das Team schlecht arbeitet – sondern weil Datenprojekte anderen Regeln folgen.
Wer schon einmal ein Data-Science-Projekt mit klassischem Scrum begleitet hat, kennt das Unbehagen nach dem ersten Sprint Review (dem Abschluss-Meeting einer Iteration, in dem Ergebnisse gezeigt werden): Das Team hat gearbeitet, Daten bereinigt, erste Modelle trainiert – aber ein auslieferbares Ergebnis? Fehlanzeige. Das Modell ist nicht konvergiert, die Datenlage war schlechter als erwartet, und das Sprint-Ziel wurde nie wirklich erreicht.
Das ist kein Versagen des Teams. Es ist ein strukturelles Missverhältnis zwischen einem Werkzeug und der Aufgabe, für die es gebaut wurde.
Warum klassisches Scrum bei Datenprojekten an Grenzen stößt
Scrum wurde Anfang der 1990er-Jahre von Ken Schwaber und Jeff Sutherland für die Softwareentwicklung entworfen. Das zugrunde liegende Versprechen: Feste Iterationen (Sprints), ein definierbares Ziel, ein auslieferbares Ergebnis. Am Ende jedes Sprints steht etwas, das funktioniert und gezeigt werden kann.
Bei klassischer Softwareentwicklung ist das realistisch. Bei Datenprojekten nicht immer.
Eine systematische Literaturauswertung von Romão et al. (2025), veröffentlicht im Rahmen der Euromicro SEAA-Konferenz 2025 (Preprint auf arXiv), identifiziert Sprint-Planung und Aufwandsschätzung als meistgenannte Problemquelle. Die Gründe liegen in der Natur von Datenprojekten selbst:
Das Problem der Nicht-Determiniertheit: Anders als bei Feature-Entwicklung lässt sich bei einem Machine-Learning-Modell nicht im Voraus zusagen, ob es nach zwei Wochen Training die gewünschte Qualität erreicht. Das Ergebnis hängt von Datenqualität, Modellarchitektur und oft unvorhersehbaren Wechselwirkungen ab.
Das Problem der Aufwandsschätzung: Story Points (eine Methode zur relativen Aufwandsschätzung in Scrum) und Velocity (die gemessene Arbeitsgeschwindigkeit eines Teams über mehrere Sprints) funktionieren, wenn Teams ähnliche Aufgaben wiederholt erledigen. Feature Engineering (die Aufbereitung und Transformation von Rohdaten für das Modelltraining), Hyperparameter-Optimierung (die Feineinstellung von Modellkonfigurationen vor und während des Trainings) und Modellvalidierung sind jedoch schlecht vergleichbar. Die Schätzungen werden zur Raterei.
Das Problem der Analyse: Im klassischen Scrum obliegt die Interpretation von Ergebnissen dem Product Owner (der Rolle, die Anforderungen priorisiert und den Wert des Ergebnisses bewertet) – außerhalb des eigentlichen Prozesses. In Datenprojekten ist die gemeinsame Auswertung von Experimenten durch das gesamte Team jedoch keine optionale Zusatzaufgabe, sondern der Kern der Arbeit.
Praxis-Beispiel: Ein Team entwickelt ein Prognosemodell für die Lieferzuverlässigkeit eines Logistikanbieters. Sprint-Ziel: Ein funktionierendes Basismodell mit einer Genauigkeit von 80 %. Nach zwei Wochen zeigt sich: Die verfügbaren Daten decken nur 60 % der relevanten Variablen ab. Das Basismodell existiert, aber die Genauigkeit liegt bei 61 %. Das Sprint-Ziel wurde formal nicht erreicht – obwohl das Team wertvolle Erkenntnisse gewonnen hat, die den weiteren Projektverlauf grundlegend verändert.
Wie Data-Driven Scrum die Schwächen von Scrum löst
Data-Driven Scrum™ (DDS) ist ein agiles Framework, das 2022 von Jeffrey Saltz (Syracuse University), Alex Sutherland (Scrum Inc.) und Nicholas Hotz (Indiana University) in einem peer-reviewed Paper auf der Hawaii International Conference on System Sciences vorgestellt wurde. Es wurde explizit entwickelt, um die bekannten Schwächen klassischer agiler Ansätze in Datenprojekten zu adressieren.
DDS zielt darauf ab, die Zusammenarbeit und Kommunikation von Data-Science-Teams zu verbessern. Das Grundprinzip klingt einfach, ist aber ein fundamentaler Bruch mit klassischem Scrum: Anstatt festzulegen, wie viel Arbeit in einer bestimmten Zeit erledigt werden kann, folgt jede Iteration drei Kernschritten: Etwas erschaffen, die Ergebnisse beobachten, und die Beobachtungen analysieren.
Die vier zentralen Unterschiede zu klassischem Scrum
1. Ergebnisbasierte statt zeitbasierte Iterationen
Der wichtigste Unterschied zwischen DDS und Scrum besteht darin, dass der Scrum Guide vorschreibt, dass alle Iterationen gleich lang sein müssen. In DDS hingegen variiert die Dauer der Iterationen, um einen logischen Arbeitsabschnitt in einer Iteration abzuschließen. Eine Iteration endet nicht nach zwei Wochen – sie endet, wenn das Experiment vollständig durchlaufen ist: erstellt, beobachtet, analysiert.
Das klingt nach einer kleinen Anpassung, ist aber eine strukturelle Befreiung: Das Team muss sich nicht mehr entscheiden, ob es ein halbfertiges Experiment ins nächste Sprint-Ziel verschiebt oder ein künstliches Inkrement präsentiert.
2. Flexible Aufwandsschätzung
Da DDS-Iterationen ergebnisbasiert sind, sind Teams nicht gezwungen, abzuschätzen, was in einer oder zwei Wochen abgeschlossen werden kann. DDS verwendet daher T-Shirt-Schätzungen auf hohem Niveau für die Priorisierung – ohne genaue Detailschätzungen zu erfordern. Das ist realistisch: Wer weiß, wie lange Modelltraining dauert, schätzt lieber „groß“ oder „klein“ als in Story Points.
3. Kollektive Analyse als Kernprozess
In vielen Scrum-Implementierungen ist das Beobachten, Analysieren und Reagieren auf Feedback allein die Verantwortung des Product Owners – dieser Teil seiner Arbeit fällt weitgehend außerhalb des formalisierten Prozesses. In DDS sind alle drei Schritte – Erstellen, Beobachten, Analysieren – direkt in den Kernworkflow integriert. Das gesamte Team wertet ein Experiment gemeinsam aus, nicht nur die Produktseite.
4. Kalenderbasierte statt iterationsgebundene Meetings
Da eine Iteration sehr kurz sein kann (zum Beispiel ein Tag für eine explorative Analyse), sollten Meetings wie Retrospektiven auf einer kalenderbasieren Frequenz stattfinden, die das Team selbst bestimmt – nicht am Ende jeder Iteration wie im klassischen Scrum. Ein tägliches Retrospektiv wäre absurd; ein monatliches macht Sinn.
Was DDS von Scrum übernimmt und was nicht
DDS ist kein Neuanfang. Es behält die bewährten Strukturelemente von Scrum bei: Rollen, Events und die Nutzung eines Item-Backlogs (der priorisierten Aufgabenliste des Teams) bleiben erhalten. Jedes DDS-Team besteht aus drei bis neun Personen, hat einen Product Owner und – anstelle des Scrum Masters – einen Process Expert.
Gleichzeitig integriert DDS zwei Kanban-Prinzipien: die Visualisierung des Workflows auf einem Task Board und die Begrenzung gleichzeitig laufender Aufgaben (Work-in-Progress-Limits). Das verhindert, dass Teams zu viele Experimente parallel beginnen, ohne eines abzuschließen.
Merksatz: DDS ist kein Ersatz für Scrum in der Softwareentwicklung. Es ist eine Erweiterung für Teams, die mit Daten, Hypothesen und Experimenten arbeiten – nicht mit Funktionen und Features.
Wann DDS sinnvoll ist und wann nicht
DDS löst spezifische Probleme. Es ist nicht universell besser als klassisches Scrum.
DDS eignet sich, wenn:
- Das Team primär mit explorativer Datenanalyse, Modellentwicklung oder Hypothesentests arbeitet
- Aufwandsschätzungen regelmäßig stark von der Realität abweichen
- Iterationen häufig mit halbfertigen Ergebnissen enden, obwohl wertvolle Erkenntnisse gewonnen wurden
- Die Analyse von Experimenten kollektiv und transparent stattfinden soll
DDS eignet sich weniger, wenn:
- KI eine Komponente eines größeren Softwareprodukts ist, das mit klassischem Scrum gut funktioniert
- Das Team produktseitig klar definierte Features liefern muss
- Stakeholder zeitgebundene Sprint Reviews und planbare Lieferrhythmen erwarten
Typischer Fehler: Teams führen DDS ein, ohne die Stakeholder auf geänderte Berichtsrhythmen vorzubereiten. Wenn ein Management-Reporting auf zweiwöchige Sprint Reviews ausgerichtet ist, entsteht Friction – nicht weil DDS falsch ist, sondern weil die Erwartungshaltung nicht angepasst wurde.
Risiken und Grenzen
Disziplin ohne feste Zeitbox: Ohne den Druck eines Sprint-Enddatums können Iterationen ausfransen. Teams, die keine eigene Disziplin in der Aufwandsbegrenzung entwickeln, riskieren endlos laufende Experimente ohne klaren Abschluss.
Stakeholder-Kommunikation: Variable Iterationslängen machen es schwerer, nach außen zu kommunizieren, was wann lieferbar ist. Das erfordert ein aktives Erwartungsmanagement gegenüber Auftraggebern und Management.
Neue Governance-Anforderungen: Da DDS mehr Autonomie im Analyseprozess gibt, steigen die Anforderungen an Dokumentation und Nachvollziehbarkeit – besonders relevant für regulierte Branchen und die Anforderungen des EU AI Acts.
Einführungsaufwand: DDS setzt voraus, dass das gesamte Team die Logik des Create-Observe-Analyze-Zyklus versteht und lebt. Das ist kein Tool-Wechsel, sondern ein Mindset-Shift – der Zeit und Begleitung braucht.
DDS, Scrum und CRISP-ML(Q): Das Zusammenspiel
Data-Driven Scrum ist kein Lifecycle-Modell – es strukturiert nicht, was ein Team in welcher Reihenfolge tun soll. Es strukturiert, wie ein Team zusammenarbeitet.
Wer DDS als Koordinationsrahmen nutzt und CRISP-ML(Q) als inhaltliche Lifecycle-Struktur, erhält eine belastbare Kombination: CRISP-ML(Q) definiert die Qualitätssicherungsschritte von der Datenvorbereitung bis zum Monitoring; DDS gibt dem Team den Raum, diese Schritte in ergebnisbasierten Iterationen zu durchlaufen, ohne sich an künstliche Zeitlimits zu binden.
Fazit
Data-Driven Scrum ersetzt klassisches Scrum nicht grundsätzlich. Es erweitert agile Arbeitsweisen dort, wo Daten, Hypothesen und Experimente den Projektalltag bestimmen. Wer KI-Projekte erfolgreich steuern möchte, sollte deshalb nicht nur Scrum kennen, sondern auch verstehen, wann spezialisierte Frameworks wie DDS oder CRISP-ML(Q) den entscheidenden Unterschied machen.
Framework-Wissen als Berufsqualifikation
Methoden wie DDS, CRISP-ML(Q) und SAFe sind keine akademischen Konzepte, die ausschließlich Entwicklungsteams betreffen. Sie prägen, wie Unternehmen KI-Projekte aufsetzen, steuern und bewerten.
Wer diese Frameworks versteht – ihre Logik, ihre Grenzen und ihr Zusammenspiel – kann fundierter entscheiden, kommunizieren und steuern. Das gilt für alle, die in KI-nahen Berufsfeldern tätig sind oder werden wollen: als Projektverantwortliche, als Schnittstelle zwischen Fachbereich und Technik, als interne Berater oder als Teamleitung.
Genau diese Art von Framework-Kompetenz – kombiniert mit Praxiswissen zu KI-Projekten, Automatisierung und strategischer Steuerung – ist Kern unserer KI-Manager Ausbildung. Praxisnah, mit anerkanntem TÜV-Zertifikat und mit bis zu 100 Prozent staatlicher Förderung über Bildungsgutschein. Programmierkenntnisse sind nicht erforderlich.
Mehr Informationen und Anmeldung: KI-Manager Ausbildung – KI-Weiterbildungszentrum
