Backlog Refinement

Ziel

Backlog Refinement gibt den Items so viel Detail und Klarheit, dass das Umsetzungsteam eine Reihe von ihnen in einer Iteration fertigstellen kann. Es beantwortet eine Asymmetrie: Ein Item gelangt als breit formulierter Bedarf ins Backlog, formuliert von jemandem, der die Arbeit nicht ausführt, und es muss das Backlog in einer Form verlassen, die ein Team umsetzt, ohne die Diskussion neu zu eröffnen.

Das Ergebnis der Tätigkeit ist eine Menge von Items, die für die nächste Iteration bereit sind, und ein im Team geteiltes Verständnis dessen, was jedes einzelne verlangt. Die Agile Extension to the BABOK Guide nennt eine zweite Wirkung: Die Sitzung gibt dem Team einen Überblick darüber, was für die Lösung als Nächstes erwartet wird.

Der Scrum Guide definiert den Vorgang unmittelbar: Product Backlog Refinement ist das Zerlegen und weitere Definieren von Einträgen des Product Backlogs zu kleineren und genaueren Einträgen. Er beschreibt es als laufende Tätigkeit, die Details wie eine Beschreibung, eine Reihenfolge und eine Grösse ergänzt. Deutschsprachige Teams verwenden durchwegs den englischen Begriff; als Übersetzung begegnen Backlog-Verfeinerung und Backlog-Pflege.

Die Abgrenzung zum Backlog-Management

Das Backlog-Management führt die Liste selbst, vom Eintritt eines Items bis zu seinem Austritt, und steht für ihre Ordnung über die Zeit ein. Das Refinement bearbeitet den Inhalt der Items, die diese Ordnung nach oben gebracht hat; die Agile Extension zählt zu seinen Tätigkeiten auch die Durchsicht der Prioritäten und das Entfernen unnötig gewordener Items, die Überschneidung zwischen den beiden Techniken. Nachgelagert wählt der Planungsworkshop unter den bereiten Items jene aus, zu deren Lieferung sich das Team für den Zeitraum verpflichtet.

Die drei Aktivitäten finden oft in derselben Woche und mitunter im selben Raum statt, was sie nicht austauschbar macht. Ohne Ordnung gibt es keinen Kopf der Liste, der zu verfeinern wäre, und ohne bereite Items wird aus der Planungssitzung eine Refinement-Sitzung, bei der das ganze Team für eine Arbeit gebunden ist, die drei Personen erledigt hätten.

Einsatz

Wann einsetzen

• Iteration beginnt in wenigen Tagen: die obersten Items vor dem Planungsworkshop vorbereiten.
• Team arbeitet im kontinuierlichen Fluss: jedes Item bei seiner Ankunft verfeinern.
• Item zu gross für eine Iteration: es in separat lieferbare Items zerlegen, von denen jedes Wert trägt.
• Rückmeldungen aus dem Betrieb zu einer gelieferten Funktion: Formulierung und Priorität der betroffenen Items überarbeiten.
• Offene Fragen zu einem vorrangigen Item: sie früh genug stellen, damit der Product Owner vor der Umsetzung antwortet.

Wann nicht einsetzen

• Backlog ohne Ordnung: mit dem Backlog-Management beginnen.
• Vision und Roadmap instabil: Das Detail wird erneuert, bevor es gedient hat; zuerst die Produktabsicht stabilisieren.

Beschreibung

Der abgestufte Detailgrad

Der Detailgrad eines Backlogs ist von Natur aus ungleich. Die obersten Items sind auf die kommende Iteration zugeschnitten und tragen genug Detail, um fertiggestellt zu werden; die unteren bleiben gross und grob. Das Refinement wirkt auf diese Abstufung: Jeder Durchgang fügt den Items, die sich der Spitze nähern, eine Stufe an Genauigkeit hinzu.

Die Agile Extension nennt die Kehrseite. Eine Story zu verfeinern, bevor sie gebraucht wird, kann Nacharbeit erzeugen. Ein Item muss erst dann bereit sein, wenn es in die Entwicklung geht, unmittelbar oder in naher Zukunft.

Die vier Elemente

Das Backlog ist die geordnete Liste der Funktionen, Anforderungen und Arbeiten, die für die erwarteten Ergebnisse der Lösung nötig sind. Das Refinement hält sie für das Team relevant und aktuell.

Das Backlog-Item trägt eine oder mehrere Anforderungen. Es tritt meist als User Story auf, mitunter als Job Story oder als Mockup. Die Zerlegung zielt auf Items, welche die INVEST-Kriterien erfüllen, den Qualitätstest einer User Story.

Die Refinement-Sitzung geht die obersten Items des Backlogs durch. Sie hat kein Standardformat und wird meist vom Product Owner oder von einer Vertretung des Kunden geführt. Sie endet mit der Bestätigung, dass die obersten Items für die nächste Iteration bereit sind, und mit der Liste dessen, was noch zu klären ist. Die Agile Extension lässt auch den informellen Weg zu, bei dem das Refinement im Lauf der Arbeit geschieht.

Die Definition of Ready ist die Menge der Kriterien, auf deren Erfüllung sich das Team einigt, um ein Item als bereit zu betrachten. Ein junges Team kann sich mit der Zustimmung einer kritischen Masse seiner Mitglieder begnügen; die Kriterien kommen später hinzu, wenn das Team aus dem lernt, was es blockiert hat. Der Begriff gehört der Agile Extension; der Scrum Guide nennt ihn nicht.

Die Kadenz folgt jener des Teams

Die Agile Extension stellt an den Anfang ihrer Grenzen das Refinement, dessen Rhythmus dem des Teams nicht folgt. Ihre Regel lautet: Die Häufigkeit des Refinements folgt jener, in der das Team sein Backlog durchsieht.

Was das Refinement scheitern lässt

Die Sitzung zu dritt

Das Refinement findet üblicherweise mit einigen Mitgliedern des Teams statt, und die Agile Extension benennt den Preis dafür: Die Sicht derjenigen, die nicht teilnehmen, fällt weg, ohne dass jemand es entschieden hätte. Der abwesende Entwickler ist derjenige, der die Abhängigkeit von einem Drittsystem kannte, und sie taucht mitten im Sprint wieder auf. Das Gegenmittel sind wechselnde Teilnehmende und eine kurze Rückmeldung in der Planungssitzung, wo das Item vor jeder Verpflichtung wieder auf das ganze Team trifft.

Zu weit im Voraus verfeinert

Im Backlog nach unten zu gehen, um einen Vorsprung zu gewinnen, ist der Reflex eines gewissenhaften Teams. Das erzeugte Detail überlebt die Rückmeldungen nicht, die eintreffen, bis das Item wieder nach oben rückt, und die nächste Sitzung diskutiert ein Item erneut, das jemand für bereits entschieden hält.

Die wachsende Definition of Ready

Eine Liste von Kriterien, die nach jedem Zwischenfall länger wird, schliesst am Ende Items aus, die das Team hätte umsetzen können. Die Agile Extension bindet diese Kriterien an das Team und an seinen Fortschritt: Es setzt sie, es überarbeitet sie. Ein Kriterium, das nie eine Blockade verhindert hat, wird so entfernt, wie es hinzugefügt wurde.

Die Sitzung, die in den Entwurf abgleitet

Ein Item an der Spitze verlangt fachliche Antworten: welche Schwelle, welcher Kanal, welcher Ausnahmefall. Sobald der Raum auf die Implementierung umschwenkt, hat der Product Owner nichts mehr zu entscheiden, und die Sitzung verbraucht die Zeit mehrerer Entwickler für eine Diskussion, die in den Sprint gehört.

KI-Überlegungen

Ein Sprachmodell liest das Backlog und meldet, was eine menschliche Durchsicht nur langsam findet: die Items, deren Beschreibung die Aufnahme der Arbeit nicht erlaubt, jene, die sich überschneiden, jene, die von einem weit unten liegenden Item abhängen. Zu einem bezeichneten Item schlägt es Zerlegungen vor und formuliert Akzeptanzkriterien in dem Format, das das Team verwendet. Es gleicht die obersten Items mit der geschriebenen Definition of Ready ab und gibt Item für Item die Liste dessen zurück, was fehlt.

Die Entscheidung, die ein Item umsetzbar macht, trifft es nicht. Die gewählte Schwelle, der gewählte Kanal, der Umgang mit Fremdwährungskonten lassen sich aus keinem Korpus ableiten: Sie werden beim Product Owner und bei der Compliance erfragt. Zur Entscheidung gedrängt, erzeugt ein Modell eine plausible Antwort, die das Team in gutem Glauben umsetzt. Der Gang durch die Definition of Ready gehört dem Team, das umsetzt, denn bereit heisst bereit für dieses Team. Ein Backlog trägt schliesslich Kundensegmente, Beträge und regulatorische Auflagen, die vor jedem Versand an ein öffentliches Modell entfernt werden.

Beispiele

Ein Team einer Westschweizer Retailbank entwickelt die Online-Banking-Anwendung und liefert in Sprints von zwei Wochen. Drei Tage vor dem Planungsworkshop nimmt sich die Refinement-Sitzung das Item vor, das die letzte Neuordnung an die Spitze gesetzt hat:

"Als Kunde möchte ich benachrichtigt werden, wenn mein Saldo unter CHF 1'000 fällt, damit ich einer Überziehung zuvorkommen kann."

Drei Fragen machen es so nicht umsetzbar: der Kanal der Benachrichtigung, die feste oder einstellbare Schwelle und der Umgang mit Fremdwährungskonten. Der Product Owner entscheidet in der Sitzung; das Team zerlegt das Item in drei, hängt jedem seine Akzeptanzkriterien an und gleicht es mit der Definition of Ready ab.

Der Product Owner nimmt die Fremdwährungskonten aus dem Release heraus; ein Item entsteht dafür nicht. Die weiter unten liegenden Items wurden während der Sitzung nicht angerührt.

Visualisierungen

Der Trichter des Refinements ist die Zeichnung, welche die Technik trägt. Das Backlog liest sich darin von unten nach oben: unten breite und grobe Items, in der Mitte eine Ebene der Refinement-Sitzung, auf der sie zerlegt, detailliert und mit Akzeptanzkriterien versehen werden, oben kleine und genaue Items. Eine Linie markiert die Definition of Ready und den Übertritt in den Planungsworkshop, die einzige Stelle der Zeichnung, an der ein Item das Backlog verlässt.

Aufwand

Werkzeuge

Die Backlog-Werkzeuge (Jira, Azure DevOps, GitLab und Vergleichbares) tragen die Tätigkeit selbst: Hierarchie von Items, Zerlegung eines Items in verknüpfte Items, eigenes Feld für die Akzeptanzkriterien, Item-Vorlage, welche die Definition of Ready als Checkliste übernimmt. Sie datieren zudem die letzte Änderung, die einzige Information, die ein verfeinertes Item von einem unterscheidet, das seit sechs Monaten wartet.

Die kollaborativen Whiteboards (Miro, Mural, FigJam und Vergleichbares) dienen der Zerlegung eines grossen Items: Karten zu verschieben lässt die Teilstücke schneller hervortreten als die Listenansicht eines Backlog-Werkzeugs. Das Ergebnis geht danach zurück ins Werkzeug, den einzigen Ort, an dem es die Woche überdauert; eine Wand und Karten leisten einem Team am selben Standort, das in einem kurzen Zeitfenster verfeinert, denselben Dienst, unter derselben Bedingung.

Die Videokonferenz mit Bildschirmfreigabe trägt die Sitzung auf Distanz, sofern der geteilte Bildschirm das Backlog-Werkzeug zeigt und die Änderungen während der Diskussion darin vorgenommen werden.

Quellen

• IIBA, Agile Extension to the BABOK Guide, §7.1 Backlog Refinement: der Zweck der Technik, ihr laufender Charakter und ihr Platz in der Vorbereitung eines Planungsworkshops, die Tätigkeiten der Ausarbeitung und der Story-Zerlegung, die Zerlegung hin zu Items, welche die INVEST-Kriterien erfüllen, die vier Elemente, Backlog, Backlog-Item, Refinement-Sitzung und Definition of Ready, sowie die genannten Stärken und Grenzen, darunter die nicht abgestimmte Kadenz und die auf wenige Mitglieder beschränkte Teilnahme.
• IIBA, Agile Extension to the BABOK Guide, §6.3.1 und §6.3.2, der Horizont Delivery: Eine Story muss erst bereit sein, wenn sie in die Entwicklung geht, sie früher zu verfeinern kann Nacharbeit erzeugen und das Refinement findet entweder in einer Sitzung oder im Lauf der Arbeit statt.
• Ken Schwaber und Jeff Sutherland, The Scrum Guide (November 2020), Abschnitt "Product Backlog": der Vorgang definiert als Zerlegung der Einträge des Product Backlogs zu kleineren und genaueren Einträgen, beschrieben als laufende Tätigkeit, die Details wie eine Beschreibung, eine Reihenfolge und eine Grösse ergänzt.