Artikel 1 von 9 in dieser Reihe.

Während des größten Teils meiner beruflichen Laufbahn war die Kapazität der Engpass bei der Produktentwicklung. Die Teams konnten nicht schnell genug entwickeln. Die Product Owner verbrachten ihre Tage damit, den Arbeitsfluss aufrechtzuerhalten: Sie verfeinerten das Product Backlog, arbeiteten die Einzelposten detailliert aus und ordneten die Aufgaben so, dass den Entwicklern nie die Arbeit ausging. Die Wertmaximierung stand ganz oben im Scrum Guide als elegantes Ziel und wurde dann in jedem Sprint in etwas viel Geringeres umgesetzt. Für viele Praktiker lief es darauf hinaus, die Details der Backlog-Elemente zu optimieren, die Teamauslastung zu maximieren und die geleistete Arbeit abzusegnen.

Die KI wird dies ändern – ich gehe davon aus, dass dies in den nächsten fünf Jahren geschehen wird. Entwicklung und Bereitstellung werden bald nicht mehr den Engpass darstellen. Stattdessen wird es zum Engpass werden, herauszufinden, was entwickelt werden soll, warum es entwickelt werden soll und wie man feststellen kann, ob es einen echten, positiven Unterschied bewirkt hat. Zum ersten Mal in der dreißigjährigen Geschichte von Scrum wird der Product Owner möglicherweise tatsächlich die Zeit haben, die im Scrum Guide beschriebene Aufgabe zu erfüllen. Die Verantwortlichkeiten im Scrum-Team werden in fünf Jahren nicht mehr dieselben sein wie heute. Mehr dazu in zukünftigen Artikeln.

Die Auswirkungen der KI werfen eine Frage auf, mit der sich viele Teams über viele Jahre hinweg nicht befasst haben: Was genau ist eigentlich Wert?

Ein visionäres Werk, das in der Realität verwurzelt ist

Dies ist ein visionärer Beitrag, kein prognostischer. Ich kann Ihnen nicht sagen, wie sich Scrum entwickeln wird. Ich kann Ihnen jedoch vermitteln, wie eine Gruppe erfahrener Professional Scrum Trainer die zukünftige Entwicklung von Scrum einschätzt und warum diese Diskussion für Ihr Team von Bedeutung ist.

Diese Blogreihe basiert auf der Präsenzveranstaltung Nr. 137 von Scrum.org (PST) , bei der Professional Scrum Trainer und die Führungsspitze von Scrum.org mehrere Tage lang darüber diskutierten, wie die Zukunft von Scrum aussehen könnte. Die vollständige Liste der Teilnehmer finden Sie am Ende dieses Artikels.

Die Ausgangslage ist ernüchternd. Die Studie „State of AI in the Enterprise 2026“ von Deloitte berichtet, dass 66 % der Unternehmen greifbare Vorteile durch den Einsatz von KI sehen, während nur 39 % ihr tatsächlich eine konkrete Wirkung zuschreiben können. Das ist die Kluft zwischen Input und Ergebnis in einer einzigen Zahl. Wie es in einem aktuellen Beitrag von Scrum.org heißt, war der Engpass nie der Code. KI beschleunigt den Teil des Systems, der eigentlich nie defekt war.

Was dieser Artikel leisten wird

Drei Punkte, kurz und bündig. Ich werde Ihnen aufzeigen, warum das Schweigen des Scrum-Leitfadens zum Thema „Wert“ zu einem Nachteil geworden ist. Ich werde ein vom Team selbst verantwortetes Artefakt vorschlagen, das ich als „Definition des Werts“ bezeichnen werde und das auf einem einfachen, dreiteiligen Test basiert. Und ich werde Ihnen vier konkrete Schritte nennen, die Sie in Ihrem nächsten Sprint umsetzen können.

Das Schweigen war beabsichtigt, und es war zu jenem Zeitpunkt richtig

Im Scrum Guide wird der Begriff „Wert“ bewusst nicht definiert. Wert ist kontextabhängig, und keine allgemeingültige Definition würde für jedes Produkt, jeden Markt und jedes Team passen. Dies war die richtige Entscheidung für ein Dokument, das branchen-, kontinent- und jahrzehntübergreifend Anwendung finden soll. Ich möchte nicht, dass jemand, der dies liest, das Argument falsch versteht. Das Auslassen des Begriffs „Wert“ war damals ein beabsichtigtes Merkmal. Die Zeiten haben sich geändert, und aus diesem Merkmal ist inzwischen technische Schuld geworden.

Etwas musste diese Lücke füllen, und Produktionsindikatoren haben diese Rolle übernommen

Geschwindigkeit. Story-Punkte. Ausgelieferte Funktionen. Teams müssen etwas messen, also messen sie das, was gerade am nächsten zur Hand ist. Das ist nicht unbedingt falsch. Es handelt sich dabei lediglich nicht um Definitionen von Wert. Es sind Aktivitätsindikatoren, von denen verlangt wird, eine Aufgabe zu erfüllen, für die sie nie konzipiert wurden.

Melissa Perri bezeichnet dies als die „Build-Falle“: Erfolg wird anhand von Outputs statt anhand von Ergebnissen gemessen. Josh Seiden definiert in seinem Beitrag „Outcomes Over Output“ ein Ergebnis als eine Veränderung des menschlichen Verhaltens, die geschäftliche Ergebnisse vorantreibt. Die Terminologie gibt es bereits seit Jahren. Das Instrument, mit dem sich dies innerhalb eines Teams in die Praxis umsetzen lässt, fehlt jedoch noch.

KI bewirkt einen entscheidenden Wandel

Als ein Sprint noch zwei Wochen dauerte, konnte ein Team einen Wertfehler erkennen, bevor zu großer Schaden entstand. Wenn ein KI-Agent in der Zeit, die man benötigt, um ein Element des Product Backlogs noch einmal durchzulesen, bereits eine funktionsfähige Funktion generieren kann, ist dieser Puffer weg. Die Kluft zwischen dem, was ein Team produzieren kann, und dem, was seine Nutzer aufnehmen können, ist zusammengebrochen.

Genau darauf liefen die Diskussionen in Amsterdam immer wieder hinaus. Der Scrum Guide muss sich von einer Output-orientierten hin zu einer ergebnisorientierten Ausrichtung entwickeln. Teams benötigen ein Hilfsmittel, um diesen Wandel tatsächlich umzusetzen. Nicht unbedingt im Scrum Guide selbst, sondern an der Wand jedes Teamraums. Verstehen Sie mich nicht falsch: Scrum hat das ergebnisorientierte Denken schon immer unterstützt und gefördert. Dennoch bleiben zu viele Teams in der „Build“-Falle stecken.

Die Definition von Wert

Wenn Sie daran interessiert sind, Ihre Arbeitsweise für das Zeitalter der KI anzupassen, wird eine „Definition of Value “ (DoV) zu einem neuen zentralen Artefakt. Die DoV wird zum zentralen Artefakt eines KI-gestützten Teams, das den Wert für das Produkt konkret, greifbar und verständlich macht. In gewisser Weise ähnelt sie der „Definition of Done“. Es geht jedoch nicht um die Qualität der von Ihnen erzeugten Ergebnisse. Vielmehr geht es darum, die zu erzielenden Ergebnisse zu klären. Das Produktteam erstellt sie gemeinsam unter der Leitung des Product Owners in Zusammenarbeit mit den wichtigsten Stakeholdern. Sie ist als Dokument an der Wand, im Wiki und ganz oben im Backlog zu finden. Sie wird regelmäßig überarbeitet und verbessert, während sich das Produkt und der Markt weiterentwickeln.

Der Zweck ist einfach: Es soll sichergestellt werden, dass alles, was das Team tut, einen Mehrwert schafft. Ist dies nicht der Fall, sollte das Team (oder die KI) keine Zeit damit verbringen, die Arbeit zu verfeinern, zu entwickeln, bereitzustellen oder zu verbreiten. Wenn die Erwartung – sprich: die Annahme – besteht, dass das Produkt einen Mehrwert schafft, sollte es so schnell wie möglich entwickelt und den Kunden und Nutzern zur Verfügung gestellt werden, damit der potenzielle Mehrwert gemessen und nachgewiesen werden kann.

Die DoVs werden je nach Produkt, Team und Branche unterschiedlich ausfallen. Was sie jedoch gemeinsam haben sollten, ist der MSA-Test:

Wo ordnet sich eine DoV innerhalb der bestehenden Scrum-Praxis ein? Vor dem evidenzbasierten Management (EBM). EBM misst den Wert im Nachhinein anhand von aktuellem Wert, nicht realisiertem Wert, Markteinführungszeit und Innovationsfähigkeit. Ein DoV definiert, was das Team überhaupt erst misst. Es steht der Produktvision nachgelagert. Die Vision gibt die Richtung vor. Ein DoV ist operativ. Und es steht neben der „Definition of Done“ (DoD). Die DoD bestätigt, dass die Arbeit korrekt ausgeführt wurde. Das DoV bestätigt, dass es sich gelohnt hat, die Arbeit zu leisten.

Wenn Sie nach einem Begriffsrahmen suchen, mit dem Sie beginnen können, bieten die „Fünf Wertarten“ von Scrum.orgeinen nützlichen Anhaltspunkt. In diesem Begleitartikel können Sie zudem die Kunst der Wertmaximierung erlernen: „Die Kunst der Wertmaximierung“. Wählen Sie eine oder zwei Wertarten aus, die für Ihr Produkt am wichtigsten sind. Nehmen Sie diese in Ihr erstes DoV auf.

Wie eine Definition von Wert in der Praxis aussieht

Abstrakte Rahmenkonzepte neigen dazu, auf dem Rückweg ins Büro in Vergessenheit zu geraten. Hier ist also ein Beispiel dafür, wie ein konkretes DoV für ein Produktteam aussehen könnte, das die Einarbeitung neuer Nutzer in ein SaaS-Produkt entwickelt.

<strong>Unsere Definition von Wert.</strong> Wir schaffen Mehrwert, wenn ein neuer Nutzer innerhalb von 72 Stunden nach der Registrierung seinen ersten Erfolgsmoment erlebt, indem er einen durchgängigen Arbeitsablauf abschließt, ohne den Support zu kontaktieren, und an mindestens einem der folgenden drei Tage wiederkehrt. Wir messen dies anhand von Aktivierungsanalysen, dem Volumen der Support-Tickets und der Rückkehrrate vom ersten bis zum siebten Tag.

Wenden Sie den MSA-Test an. Messbar: drei Datenpunkte, die alle abfragbar sind. Signifikant: Die Aktivierung ist der Frühindikator für die Kundenbindung, die wiederum den Umsatz steigert. Angewandt: Jede Kennzahl misst, was Nutzer tatsächlich tun, und nicht, ob eine Funktion vorhanden ist. Der DoV-Test ist bestanden. Ein Team kann nun in die Verfeinerungsphase übergehen und für jedes Element des Product Backlogs fragen: Trägt dieses Element, falls es umgesetzt wird, zur Erfüllung dieser Definition bei? Wenn ja, gehört es in den Sprint. Wenn nein oder wenn niemand eine Aussage dazu treffen kann, wird es zur Präzisierung zurückgeschickt.

Stellen Sie sich nun dasselbe Team ohne „Definition of Done“ vor. Es liefert einen neu gestalteten Onboarding-Ablauf in zwei Sprints aus. Die „Definition of Done“ ist erfüllt. Das Release verläuft reibungslos. Drei Wochen später haben nur 18 % der neuen Nutzer den neuen Ablauf genutzt, da dieser die Umstellung einer Einstellung erfordert, zu der sie von niemandem aufgefordert werden. Jede Sprint-Verpflichtung wurde eingehalten. Es wurde jedoch kein Mehrwert geliefert. Mit der oben genannten „Definition of Done“ hätte das Product-Backlog-Element die Verfeinerung nicht überstanden; die Abhängigkeit vom Umschalter hätte die 72-Stunden-Metrik zunichte gemacht, noch bevor eine einzige Zeile Code geschrieben worden wäre.

Das ist der Unterschied, den eine einvernehmlich festgelegte Definition von Wert bewirken könnte.

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

Ein fünfter Schritt, falls Sie EBM bereits einsetzen: Ordnen Sie jede DoV-Aussage mindestens einem Schlüsselwertbereich zu. Die beiden Elemente ergänzen sich gegenseitig und gewinnen dadurch an Wirksamkeit.

Die Wende

Das Schweigen des Scrum-Leitfadens zum Thema „Wert“ war noch verkraftbar, als die Auslieferung den Engpass darstellte. Die Umgehungslösung – Output-Proxies – reichte aus, um Software ohne Blamage auszuliefern. Die KI nimmt uns dieses Polster weg. Für den Product Owner ist dies keine Bedrohung. Es ist die erste echte Chance seit dreißig Jahren, die Arbeit zu leisten, die der Scrum-Leitfaden fordert. Maximieren Sie den Wert. Nicht die Details der Backlog-Elemente. Nicht die Auslastung des Teams. Tatsächlichen, nachgewiesenen und umgesetzten Wert.

Eine Definition von „Wert“ besagt, wie Sie dies in Ihrem Team in diesem Sprint konkret umsetzen, ohne darauf zu warten, dass jemand den Leitfaden überarbeitet.

Nun sind Sie an der Reihe

Ich bin neugierig, wie eine Definition von „Wert“ in Ihrem Team aussieht. Was gilt bei dem Produkt, an dem Sie derzeit arbeiten, als Wert? Könnten Sie diese Frage in einem Satz beantworten? Falls ja, würde ich das gerne lesen. Falls nicht, wäre das ein Thema für ein Gespräch mit Ihrem Team in dieser Woche.

Der nächste Artikel dieser Reihe wirft eine schwierigere Frage auf. Wenn KI-Agenten immer mehr Aufgaben übernehmen, wer trägt dann die Verantwortung für das Ergebnis? 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__________________________Lesen Sie den nächsten Artikel>

Quellen

Der Engpass lag nie im Code, Scrum.org

Evidenzbasiertes Management, Scrum.org

Fünf Arten von Wert, Scrum.org

Die Kunst der Wertmaximierung, Robbin Schuurman (Medium)

„Der Build-Falle entkommen“, Melissa Perri (Zusammenfassung)

Ergebnisse statt Output, Josh Seiden

Der Stand der KI in Unternehmen 2026, Deloitte