Artikel

Vom nutzbaren Zwischenergebnis zur eingesetzten und übernommenen Lösung

Eine sinnvolle Neuerung schafft nur dann einen Mehrwert, wenn die Menschen sie annehmen, nutzen und ihr Verhalten aufgrund dieser Neuerung ändern.

Robbin Schuurman

Aktualisiert Oktober 15, 2026

9 Minuten

Artikel 4 von 9 in dieser Reihe.

Stellen Sie sich ein Team vor, dessen Erfolgsserie jeden Scrum-Master mit Stolz erfüllen würde. Zwölf Sprints in Folge, bei denen alle Sprint-Ziele erreicht wurden. Jedes Inkrement erfüllt die „Definition of Done“. Jedes Release wird reibungslos bereitgestellt. Jede Retrospektive endet mit grünen Lichtern auf der Tafel.

Die Produktakzeptanz verläuft seit einem Quartal unverändert.

Das Inkrement ist einsatzfähig. Der Code läuft. Die Funktionen funktionieren. Die „Definition of Done“-Leiste wird jedes Mal abgearbeitet. Bei dem einzigen Test, der für ein Produktteam wirklich zählt – nämlich ob echte Nutzer das Produkt tatsächlich nutzen und annehmen –, scheitert das Inkrement still und leise. Zwölf Sprints voller Bewegung, null Sprints mit Verhaltensänderungen. Nutzbar, ja. Genutzt und angenommen, nein.

Im ersten Artikel dieser Reihe habe ich eine Definition von Wert vorgeschlagen. Im zweiten habe ich dargelegt, dass sich die Verantwortlichkeit konzentriert, sobald Akteure dem Team beitreten. Im dritten Artikel habe ich die Verfeinerung als eine Übung zur Gestaltung von Optionen neu definiert. Dieser Artikel wirft eine schwierigere Frage auf: Wenn KI mit im Raum ist, was gilt dann tatsächlich als Inkrement, und wie sieht der Weg von einem nutzbaren Inkrement zu einer genutzten und eingeführten Lösung aus?

Dies ist ein visionärer Beitrag, kein prognostischer. Ich kann Ihnen nicht sagen, wie sich die Definition des Begriffs „Inkrement“ im Scrum Guide weiterentwickeln wird oder sollte. Ich kann Ihnen jedoch darlegen, wie eine Gruppe erfahrener Professional Scrum Trainer darüber denkt und warum Ihr Team in diesem Sprint strengere Maßstäbe anlegen muss, als es der Guide derzeit vorsieht. Die vollständige Liste der Mitwirkenden des Face-to-Face-Events in Amsterdam finden Sie am Ende des Artikels. Die hier vorgebrachten Argumente stammen von mir. Die Überlegungen stammen von uns.

Der Scrum Guide hat sich aus gutem Grund für „Usable“ entschieden

Der Scrum Guide definiert das Inkrement als „einen konkreten Schritt in Richtung des Produktziels“. Es muss nutzbar sein. Es muss einen Mehrwert bieten. Es muss verifiziert werden. Das war im Jahr 2020 eine hohe, anspruchsvolle und berechtigte Messlatte. Viele Teams haben diese nicht zuverlässig erreicht. Es war keine Seltenheit, dass Teams unfertige Funktionen, fehlerhafte Builds und teilweise aktivierte Feature-Flags auslieferten. Der Begriff „nutzbar“ war ein Begriff, der strenge Maßstäbe setzte.

Machen Sie keinen Fehler: Das Scrum-Handbuch war zu jener Zeit richtig. Die darin festgelegten Maßstäbe waren genau die richtigen, um den Engpass zu überwinden, mit dem die Branche zu kämpfen hatte. „Nutzbar“ und „verifiziert“ unterschieden professionelle Teams von den übrigen.

KI verschiebt die Schwelle erneut

Der Engpass hat sich verlagert. KI-Agenten sind nun in der Lage, funktionsfähigen, einsetzbaren und nutzbaren Code in einem Tempo zu erstellen, das die meisten Teams bisher noch nicht erlebt haben. „Nutzbar“ ist nach wie vor ein bedeutungsvoller Begriff. Er ist jedoch nicht mehr mit nennenswerten Schwierigkeiten verbunden. Wenn Inkremente schneller eintreffen, als die Nutzer sie verarbeiten können, ist die Bereitstellung nutzbarer Software kein Unterscheidungsmerkmal mehr zwischen Teams, die Wert schaffen, und solchen, die nur für Bewegung sorgen.

Die nächste Schwelle ist bereits in Sicht, und die Amsterdamer Gruppe umkreiste sie immer wieder: Eine Weiterentwicklung ist nur dann wirklich vorhanden, wenn sie genutzt und angenommen wird.

Die Studie „State of AI in the Enterprise 2026“ von Deloitte zeigt, dass 66 % der Unternehmen von greifbaren Vorteilen durch den Einsatz von KI berichten, während nur 39 % der Unternehmen der KI tatsächlich eine konkrete Wirkung zuschreiben können. Das ist dieselbe Lücke zwischen Output und Ergebnis, mit der ich diese Serie eingeleitet habe. Auf der „Increment“-Ebene handelt es sich dabei um die Lücke zwischen dem, was nutzbar ist, und dem, was nicht genutzt wird.

Die Zunahme der Adoptionen

Ich möchte eine präzisere Definition vorschlagen, die parallel zum Scrum Guide verwendet werden kann, anstatt diesen zu ersetzen. Nennen wir sie „Adoption Increment“.

Ein Akzeptanzschritt ist ein Schritt, der (1) die Definition von „Fertig“ erfüllt, (2) von einem namentlich genannten Nutzer für den vorgesehenen Zweck genutzt wurde und (3) innerhalb eines festgelegten Feedback-Zeitraums beobachtbare, messbare Belege für die Akzeptanz erbracht hat.

Drei Punkte. Alle drei sind erforderlich. Die „Definition of Done“ stellt sicher, dass die Arbeit korrekt ausgeführt wurde. Die Akzeptanz stellt sicher, dass sich die Arbeit gelohnt hat. Beide sind notwendig. Keiner allein reicht aus.

Falls Ihnen diese Formulierung bekannt vorkommt, ist das kein Zufall. Es handelt sich um die Zeile „Adopted“ des MSA-Tests aus dem ersten Artikel dieser Reihe, die auf der Ebene des Inkrements konkretisiert wurde. Die „Definition of Value“ legt fest, was zählt. Das „Adoption Increment“ legt fest, wann es zählt.

Wo dies innerhalb von Scrum angesiedelt ist

Das „Adoption Increment“ erweitert die „Definition of Done“. Es ersetzt diese nicht. Der Product Owner ist dafür verantwortlich, dass ein bestimmtes Inkrement die Akzeptanzhürde genommen hat. Die Entwickler sind dafür verantwortlich, das Inkrement so zu gestalten, dass die Akzeptanz beobachtbar ist. Der Scrum Master ist dafür verantwortlich, die Disziplin zu wahren, damit „ausgeliefert“ nicht stillschweigend zum Synonym für „fertig“ wird.

In der Praxis bedeutet ein „Adoption Increment“, dass drei Mechanismen in die Arbeitsvereinbarung des Teams aufgenommen werden.

Pilotkohorten und Feature-Flags. Jedes nicht-triviale Increment wird über ein Flag an eine benannte Kohorte ausgeliefert. Dabei handelt es sich um echte Nutzer in einer echten Kohorte, nicht um synthetischen Traffic.

Instrumentierung zur Einführung, die im Lieferumfang der Funktion enthalten ist. Was auch immer das Team bei der Verfeinerung gesagt hat, gilt als Nachweis im Sinne des „Option Frame“ aus Artikel 3 und ist am ersten Tag der Veröffentlichung bereits einsatzbereit. Agenten sind hervorragend darin, diese Instrumentierung aufzubauen. Es obliegt den Menschen, zu entscheiden, ob der Nachweis die Anforderungen erfüllt hat.

Ein zeitlich begrenzter Zeitraum für die Einführung. Sieben Tage sind ein angemessener Ausgangspunkt. Bevor das Zeitfenster endet, gilt das Inkrement als zu prüfende Hypothese. Nach Ablauf des Zeitfensters wertet das Team die Ergebnisse aus und entscheidet: angenommen, nicht angenommen oder nicht eindeutig. Wird der Punkt nicht angenommen, geht er zurück in die Verfeinerungsphase. Entweder war die Hypothese falsch oder der Rahmen war falsch. Beides ist aufschlussreich.

Wie dies in der Praxis aussieht

Kehren wir zum SaaS-Onboarding-Team aus dem ersten Artikel zurück. Es stellt einen neu gestalteten Onboarding-Ablauf bereit, der die „Definition of Done“ erfüllt. Die alte Geschichte endete an dieser Stelle, und das Team war stolz auf die Veröffentlichung. Die neue Geschichte, die im Rahmen der „Adoption Increment“-Methode verläuft, dauert noch weitere sieben Tage an.

Tag drei: Nur 11 % der neuen Nutzer haben den neuen Ablauf bereits genutzt. Die Funktion erfordert die Aktivierung einer Einstellung, zu deren Umstellung niemand aufgefordert wird. Tag fünf: Die Anzahl der Support-Anfragen zum Onboarding ist leicht gestiegen. Tag sieben: Die Akzeptanz liegt bei 18 %. Das in der Verfeinerungsphase festgelegte Ziel betrug 60 %.

Gemäß einer Regel zur schrittweisen Einführung ist das Inkrement noch nicht abgeschlossen. Das Kennzeichen bleibt für die Kohorte aktiv. Das Element wird zur weiteren Verfeinerung zurückgeführt. Das Team formuliert eine neue Wette im Optionsrahmen: „Wir sind davon überzeugt, dass die Entfernung des Einstellungsschalters und die automatische Aufforderung zum neuen Ablauf die Akzeptanz auf über 60 % steigern werden.“ Die Entwickler sind nicht entmutigt. Sie befinden sich genau dort, wo sie sein sollten, nämlich in der Lernschleife, in der der Scrum Guide sie schon immer haben wollte – nur dass sie nun über Belege verfügen, die diese Behauptung untermauern.

Vergleichen Sie dies mit zwölf Sprints nach dem Motto „ausgeliefert, DoD-Anforderungen erfüllt, weitergegangen“. Die gleiche Menge an Code. Völlig unterschiedliche Produktergebnisse.

Vier Maßnahmen, die Sie in Ihrem nächsten Sprint umsetzen können

Fügen Sie Ihrer „Definition of Done“ eine „Adopted“-Klausel hinzu. Kurz, konkret, messbar. Etwa so: „Ein Inkrement gilt als abgeschlossen, wenn es die Anforderungen an Benutzerfreundlichkeit und Qualität erfüllt und wenn eine namentlich genannte Kohorte es innerhalb von sieben Tagen für den vorgesehenen Zweck genutzt hat.“ Bitte nach Belieben anpassen.

Liefern Sie jedes Element des Product Backlogs mit integrierten Instrumenten zur Überwachung der Akzeptanz aus. Falls die Daten am ersten Tag der Veröffentlichung nicht gemessen werden können, war die Zeile „Option Frame“ unter „Evidence“ nicht korrekt. Korrigieren Sie die Verfeinerung, nicht das Dashboard.

Legen Sie einen Zeitraum von sieben Tagen für die Adoption fest. Solange dieses Zeitfenster noch offen ist, stellt das Increment eine Hypothese dar. Nach Ablauf dieses Zeitfensters prüft das Team die Belege und erklärt die einzelnen Punkte für angenommen, nicht angenommen oder als nicht eindeutig. Nicht angenommene Punkte werden zur weiteren Ausarbeitung zurückverwiesen.

Bitte führen Sie in Ihrer Retrospektive die Inkremente auf, die die DoD-Prüfung bestanden haben, deren Einführung jedoch gescheitert ist. Das sind die Punkte, aus denen man im Sprint am meisten lernen kann. Ein Team, das diese Gespräche in den Vordergrund stellt, wird mit jedem Sprint schlagkräftiger. Ein Team, das sie verschweigt, bleibt für immer in der „Build-Falle“ gefangen.

Die Wende

Seit dreißig Jahren gilt es im Scrum als Grundsatz, unfertige Arbeit abzulehnen. Entwickler geben keine fehlerhaften Builds frei. Teams nehmen keine unausgereiften Stories in einen Sprint auf. Qualitätsfachleute, die der Scrum-Tradition folgen, reagieren zu Recht allergisch auf den Ausdruck „gut genug“.

In einer von KI geprägten Welt benötigt dieselbe Gemeinschaft dieselbe Disziplin im Umgang mit noch nicht implementierten Arbeiten. Das Increment, das Ihr Team in diesem Sprint bereitstellt, ist nicht das Ergebnis. Es ist die Hypothese. Die Belege innerhalb Ihres Implementierungsfensters sind das Ergebnis.

Nun sind Sie an der Reihe

Wählen Sie das letzte Increment aus, das Ihr Team veröffentlicht hat. Stellen Sie zwei Fragen: Entsprach es der Definition of Done? Und hat ein echter Nutzer aus einer echten Kohorte es innerhalb von sieben Tagen für den vorgesehenen Zweck genutzt? Wenn die Antwort auf die erste Frage „Ja“ und auf die zweite „Nein“ oder „unbekannt“ lautet, haben Sie das Gespräch, das Ihr Team diese Woche benötigt.

Der nächste Artikel befasst sich mit dem Scrum-Event, bei dem sich „Adoption Increments“ nirgendwo verstecken können: dem Sprint Review. Wird das Sprint Review ehrlich durchgeführt, wird es zur entscheidenden Stunde des Sprints. Wird es so durchgeführt, wie es die meisten Teams nach wie vor handhaben, ist es lediglich eine Demo-Veranstaltung mit einem Feedback-Formular. Ich möchte mich für eine Alternative aussprechen. Wir sehen uns dort.

Mitwirkende

Dieser Artikel entstand auf der Grundlage der PST-Präsenzveranstaltung Nr. 137 von Scrum.org in Amsterdam. Er wäre ohne die Gespräche mit folgenden Personen nicht möglich gewesen: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton und Karel Smutný. Die hier dargelegten Argumente stammen von mir. Die Überlegungen stammen von uns.

< Lesen Sie den vorherigen Artikel