Artikel 3 von 9 in dieser Reihe.

Stellen Sie sich eine Verfeinerungssitzung vor, die von außen betrachtet wie ein Musterbeispiel für bewährte Vorgehensweisen wirkt. Zehn Elemente des Product Backlogs wurden überprüft. Die Akzeptanzkriterien wurden präzisiert. Story-Punkte wurden zugewiesen. Abhängigkeiten wurden gekennzeichnet. Alle gehen pünktlich nach Hause. Jedes Element scheint für den nächsten Sprint bereit zu sein.

Fragen Sie nun die Anwesenden, warum auch nur einer dieser zehn Punkte für das Produkt einen entscheidenden Unterschied machen wird. In der Diskussion ging es darum, wie – und ausschließlich darum, wie. In einer von KI geprägten Welt ist dies die falsche Diskussion, die man führen sollte.

Im ersten Artikel dieser Reihe habe ich eine Definition von Wert als das zentrale Artefakt des Teams vorgeschlagen. Im zweiten Artikel habe ich dargelegt, dass sich die drei Scrum-Verantwortlichkeiten bündeln, anstatt sich aufzulösen, sobald die Akteure in die Arbeit einsteigen. Dieser dritte Artikel befasst sich mit der Praxis, in der diese beiden Stränge aufeinandertreffen und jede Woche in die Tat umgesetzt werden: die Verfeinerung des Product Backlogs. Es lohnt sich, dies gleich zu Beginn zu erwähnen, da der Rest des Artikels darauf aufbaut: Die Verfeinerung ist laut Scrum Guide eine fortlaufende Aktivität und gehört nicht zu den fünf Scrum-Events. Die fünf Events sind der Sprint, die Sprint-Planung, das Daily Scrum, die Sprint-Review und die Sprint-Retrospektive. Die Verfeinerung ist die Praxis, die dafür sorgt, dass diese Events funktionieren.

Dies ist ein visionärer Beitrag, kein prognostischer. Ich kann Ihnen nicht genau sagen, wie sich die Verfeinerung in den nächsten fünf Jahren verändern wird. Ich kann Ihnen jedoch darlegen, wie sich die Verfeinerung nach Ansicht einer Gruppe erfahrener Professional Scrum Trainer weiterentwickeln muss und warum dieser Wandel für Ihr Team in diesem Sprint von Bedeutung ist. Die vollständige Liste der Mitwirkenden der Präsenzveranstaltung in Amsterdam finden Sie am Ende des Artikels. Die hier dargelegten Argumente stammen von mir. Die Überlegungen stammen von uns.

Verfeinerung bedeutete Zerlegung, als das Angebot knapp war

Während des größten Teils meiner beruflichen Laufbahn bedeutete „Verfeinerung“ in der Praxis vor allem eines: Man nimmt ein Element aus dem Product Backlog, präzisiert die Akzeptanzkriterien, gliedert die Arbeit auf, schätzt den Aufwand ab und übergibt es den Entwicklern in einer Form, die sie innerhalb eines Sprints umsetzen können. Dies ist eine sinnvolle Anwendung dieser Praxis, wenn die Entwicklungskapazität den Engpass darstellt. Die Entwickler sind teuer und arbeiten langsam. Die Aufgabe der Verfeinerung besteht darin, sie kontinuierlich mit Arbeit zu versorgen, mit der sie sofort beginnen können.

Machen Sie keinen Fehler: Die Beschreibung der Verfeinerung im Scrum Guide hat schon immer mehr als nur eine Aufgliederung zugelassen. Verfeinerung wird als Hinzufügen von Details, Ordnung und Verständnis beschrieben. Der Guide hat das Denken in Optionen nie verboten. Die Teams haben die Verfeinerung eingeschränkt, nicht der Guide. Der Engpass hat dies erforderlich gemacht.

Die neue Knappheit ist die Qualität der Optionen

KI-Agenten haben den Engpass beseitigt. Die Generierung von Optionen ist nicht mehr ressourcenintensiv. Die Ausarbeitung von Akzeptanzkriterien verläuft nicht mehr langsam. Das Erstellen von Code-Gerüsten stellt keine Einschränkung mehr dar. Ein Agent kann drei realisierbare Ansätze für eine Funktion in der Zeit erarbeiten, die ein Entwickler früher benötigte, um den ersten Satz einer Entwurfsskizze zu verfassen.

Was heute Mangelware ist und was schon immer das Wichtigste war, ist die Qualität der Entscheidungsfindung: zu wissen, welche Entscheidung man treffen soll, warum man sie trifft und welche Erkenntnisse man sich davon verspricht. Genau darin liegt das menschliche Urteilsvermögen. Genau darauf muss sich die Weiterentwicklung nun konzentrieren.

Der Optionsrahmen

Was sollte Ihr Team also im Rahmen der Verfeinerung tun, anstatt eine Dekomposition durchzuführen? Ersetzen Sie die Checkliste zur „Definition of Ready“ durch eine vierzeilige Struktur, die ich als „Option Frame“ bezeichnen werde. Hängen Sie diese an die Wand, neben die „Definition of Value“ aus dem ersten Artikel.

Ergebnis. Auf welche Veränderung im Nutzer- oder Geschäftsverhalten setzen wir? Dieser Satz muss sich auf eine Aussage in Ihrer Wertdefinition beziehen.

Optionen. Was sind die drei plausibelsten Wege, wie wir dieses Ergebnis erreichen könnten? Ein Agent ist hervorragend darin, solche Vorschläge zu erarbeiten. Der Product Owner und die Entwickler sind dafür verantwortlich, diese zu filtern und auf ihre Tragfähigkeit zu prüfen.

Wette. Für welche Option entscheiden wir uns, und warum? Dies ist eine Ermessensentscheidung des Menschen. Der Product Owner unterzeichnet. Die Entwickler bestätigen die Machbarkeit. Ein Bearbeiter kann diese Zeile nicht zurückhalten.

Beweismittel. Was werden wir beobachten, wenn die Hypothese zutrifft? Was werden wir beobachten, wenn dies nicht der Fall ist? Denken Sie dabei an Frühindikatoren, Signale für die Akzeptanz und falsifizierbare Gegenargumente. Ein Agent kann dabei helfen, Definitionen für Belege aus historischen Daten zusammenzufassen. Die Entscheidung, welche Belege zählen, liegt weiterhin beim Team.

Wenn eine Zeile nicht beantwortet werden kann, ist das Element nicht konkretisiert. Es ist nicht bereit für einen Sprint. Es handelt sich um eine unkonkrete Option, die vorgibt, eine Verpflichtung zu sein.

Wo Agenten hingehören – und wo nicht

Der Optionsrahmen verdeutlicht zudem die Arbeitsteilung zwischen Mensch und Agent.

Agenten gehören in den Bereich „Optionen“: Generieren, Strukturieren und Variieren. Sie gehören in den Bereich „Evidenz“: Maßnahmen vorschlagen, historische Daten abfragen, die Dashboard-Abfragen vor Beginn des Sprints entwerfen. Sie gehören nicht in die Bereiche „Ergebnis“ oder „Wette“. In diesen Zeilen kommen Produktbeurteilung, Abstimmung mit den Stakeholdern und Verantwortlichkeit zum Tragen. Dies sind die Zeilen, die ich in Artikel 2 als die entscheidenden Punkte des Betriebsmodells des Teams bezeichnet habe.

Anders ausgedrückt: Agenten generieren und synthetisieren. Menschen kontextualisieren und entscheiden. Bei der Verfeinerung kommt dieser Unterschied zum Tragen.

Eine provokante Betrachtung zum Product Backlog selbst

Erwähnenswert ist in einem Exkurs ein Gespräch, das in Amsterdam immer wieder zur Sprache kam. Wenn ein Agent auf Abruf genau die zehn richtigen Optionen für das gewünschte Ergebnis in dem Moment generieren kann, in dem das Team sie benötigt, braucht das Team dann überhaupt noch ein langes, geordnetes Product Backlog im herkömmlichen Sinne? Oder schrumpft das Product Backlog zu einer kurzen Liste aktueller „Live Bets“, einer Auswahl an Optionen im Umfang des aktuellen Sprints und einer Arbeitsdefinition von Wert, die der Agent abfragen kann, um den Rest neu zu generieren?

Verstehen Sie mich bitte nicht falsch: Ich behaupte keineswegs, dass das Product Backlog verschwinden wird. Das Product Backlog gemäß dem Scrum Guide – eine sich herausbildende, geordnete Liste der erforderlichen Elemente – ist heute genauso zutreffend wie im Jahr 2020. Was ich jedoch behaupte, ist, dass das Artefakt, das viele Teams pflegen – eine Liste mit tausend Einträgen, die übermäßig aufbereitet und nie gelesen wird –, eine Gewohnheit aus der „Delivery-Ära“ ist, die bald überholt sein wird. Das Product Backlog eines KI-gestützten Teams dürfte kleiner, prägnanter, meinungsstärker und enger mit der Definition von Wert verknüpft sein, als es die meisten Tools, die Teams heute verwenden, voraussetzen. Das ist eine provokante These, über die es sich lohnt, nachzudenken – selbst wenn Ihr Team sich vorerst dafür entscheidet, das bestehende Backlog beizubehalten.

Wie dies in der Praxis aussieht

Stellen Sie sich ein Fintech-Team vor, das einen Eintrag im Product Backlog zur Verbesserung eines grenzüberschreitenden Zahlungsablaufs verfeinert. Bei einer klassischen Verfeinerungssitzung würden die Akzeptanzkriterien präzisiert, über Randfälle für drei Währungen diskutiert und eine Fünf-Punkte-Schätzung vorgenommen. Alle würden zufrieden nach Hause gehen.

In einer KI-gestützten Verfeinerungssitzung öffnet der Product Owner den „Option Frame“. Ergebnis: Reduzierung der Abbruchrate bei der ersten Zahlung für neue KMU-Kunden um dreißig Prozent, direkt verknüpft mit dem DoV des Teams zur Aktivierung. Optionen: Das Team nutzt einen Agenten, um drei plausible Varianten zu generieren: einen integrierten Währungsvorschlag, ein Transparenz-Panel zum Wechselkurs vor der Zahlung und einen Ablauf mit gespeicherten Empfängern per einem Fingertipp. Zwei Entwickler erkennen innerhalb von zehn Minuten ein verstecktes Risiko in der ersten Variante. Hypothese: das Transparenz-Panel für Wechselkurse, da das Team davon ausgeht, dass der Abbruch durch Unsicherheit und nicht durch Reibungspunkte verursacht wird. Belege: Konversionsrate bei der KMU-Aktivierung im Ablauf der ersten Zahlung, gemessen über vierzehn Tage; Support-Tickets, in denen Wechselkurse erwähnt werden; durchschnittliche Verweildauer auf dem Panel. Fertig. Fünfundzwanzig Minuten, ein Punkt, eine Hypothese, die das gesamte Team erklären kann.

Vergleichen Sie nun beide Ergebnisse. Die klassische Sitzung führte zu einem gut zerlegten Element. Die „Option Frame“-Sitzung führte zu einer gut strukturierten Wette. Beides sieht nach Verfeinerung aus. Doch nur eines davon entspricht dem, was Verfeinerung eigentlich sein sollte.

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

Befestigen Sie den Option-Rahmen an der Wand. Vier Zeilen. In jeder Verfeinerungssitzung sichtbar. Wenn Sie die „Wertdefinition“ bereits geöffnet haben, sollte die Zeile „Ergebnis“ buchstäblich darauf verweisen.

Lassen Sie von einem Makler drei bis fünf Angebote für eine Immobilie erstellen. Es geht nicht darum, eine auszuwählen, sondern darum, sie ans Licht zu bringen. Der Product Owner und die Entwickler filtern sie anschließend heraus, unterziehen sie einer Belastungsprüfung und treffen eine Entscheidung. Legen Sie für den Generierungsschritt ein Zeitlimit von zehn Minuten fest.

Verzichten Sie auf die „Definition der Bereitschaft“ als Checkliste und ersetzen Sie diese durch den Optionsrahmen. Ihre bisherige Definition von „bereit“ bestand darin, diesen Auftrag ausführen zu wollen. Es fehlte jedoch stets an der Struktur, um das Gespräch in Gang zu bringen. Der „Option Frame“ bietet diese Struktur.

Lesen Sie am Ende der Verfeinerung die These und die Belege vor. Laut aussprechen. Sollte jemand aus dem Team nicht in der Lage sein, den Punkt in einem Satz wiederzugeben, ist dieser noch nicht ausgereift. Schicken Sie ihn zurück – nicht, um ihn abzulehnen, sondern um ihn zu präzisieren.

Die Wende

Seit dreißig Jahren ist die Verfeinerung die Methode, mit der Teams ihre Arbeit aufschlüsseln. In einem KI-gestützten Team wird die Verfeinerung zur Methode, mit der Teams ihre Hypothesen formulieren. Die Aufschlüsselung wird von Monat zu Monat kostengünstiger. Das Urteilsvermögen hingegen nicht. Die wertvollsten dreißig Minuten Ihres Sprints – sobald die Teammitglieder im Raum versammelt sind – sind jene, in denen Sie entscheiden, was Sie bewusst nicht entwickeln werden und welche Erkenntnisse Sie aus Ihrer Arbeit zu gewinnen hoffen.

Nun sind Sie an der Reihe

Betrachten Sie die letzten drei Elemente, die Ihr Team ausgeliefert hat. Fragen Sie sich bei jedem einzelnen: Was war das Ergebnis, welche anderen Optionen gab es, auf welche Strategie haben wir gesetzt und welche Belege haben gezeigt, dass wir Recht oder Unrecht hatten? Wenn Sie diese Fragen nicht in vier Sätzen beantworten können, ist das Verfeinerungsgespräch der richtige Ort, um dies zu korrigieren. Nicht die Sprint-Review.

Der nächste Artikel wirft eine unbequeme Folgefrage auf. Wenn die Verfeinerung der Phase ist, in der Entscheidungen getroffen werden, dann ist das Inkrement die Phase, in der diese Entscheidungen auf die Probe gestellt werden. Warum liefern dann so viele Teams ein „brauchbares“ Inkrement aus, das eigentlich niemand nutzt? 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

Quellen

Was ist die Verfeinerung des Product Backlogs?, Scrum.org

Der Scrum Guide, Schwaber und Sutherland

Gewohnheiten für kontinuierliches Lernen, Teresa Torres

Inspiriert von Marty Cagan

Ergebnisse statt Output, Josh Seiden

Die Definition von Wert steht im Mittelpunkt – Artikel 1 dieser Reihe

Man kann die Verantwortung nicht an einen Beauftragten delegieren – Artikel 2 dieser Reihe