So verfeinert ihr euren Backlog effizienter – durch strukturierte Vorbereitung

Wie ich in meinem vorherigen Blog beschrieben habe, betreiben die meisten Teams nicht ausreichend Backlog Refinement. In vielen Fällen liegt das an teaminternen Widerständen: Teams empfinden Backlog Refinement möglicherweise als Zeitverschwendung. Sie halten es für so ineffizient, Arbeitspakete vor Beginn zu definieren, dass sie lieber die Verschwendung in Kauf nehmen, einfach losarbeiten und auf die harte Tour herausfinden, was zu tun ist.

Was tun, wenn euer Team Backlog Refinement nur widerwillig betreibt?

Es gibt verschiedene Möglichkeiten, mit Widerständen im Team umzugehen:

1. Konzentriert euren Refinement-Aufwand auf nicht routinemäßige Aufgaben

2. Prüft, ob die Teilnahme des gesamten Teams sinnvoll ist oder ob ihr das Refinement mit einer kleineren Gruppe durchführen solltet

3. Organisiert die Vorbereitung der Items besser

Routinemäßige Aufgaben profitieren normalerweise nicht von Refinement. Für diese Aufgaben gibt es bereits ungeschriebene „Akzeptanzkriterien“, die das Team gut kennt. Überspringt diese Items – es sei denn, jemand stellt fest, dass eine Aufgabe, die wie Routine aussieht, es tatsächlich nicht ist.

Ich befürworte zwar die Teilnahme des gesamten Teams an Backlog-Refinement-Sessions, bei großen Teams ist das jedoch möglicherweise nicht sinnvoll. Bei einem Team mit fünf Mitgliedern sollte jeder teilnehmen. Bei zehn oder mehr Teammitgliedern solltet ihr erwägen, das Refinement nur mit ausgewählten Teilnehmern durchzuführen. Der Informationsaustausch ist zwar ein zentraler Vorteil des Refinements, lässt sich aber auch auf andere, effizientere Weise erreichen.

In diesem Blog gehe ich nun detailliert auf den dritten Punkt der Liste ein – eine bessere Vorbereitung.

Entwickelt einen strukturierten Vorbereitungsansatz für Backlog Refinement

Im Folgenden wird beschrieben, wie ihr euer Backlog Refinement durch eine strukturiertere Vorbereitung ergänzt. In meinem vorherigen Blog findet ihr den gesamten Refinement-Prozess.

Vorbereitung vor der Session: 

1. Der Product Owner wählt die Items aus, die Refinement erfordern.

2. Der Product Owner sucht im Entwicklungsteam eine geeignete Person, die die Items weiter vorbereiten kann. Alternativ organisiert sich das Team selbst und findet die am besten geeignete Person, die die Verantwortung für die Vorbereitung übernimmt.

3. Die ausgewählten Teammitglieder bereiten die Items vor.

4. Der Product Owner schickt den Teilnehmern der Refinement-Session eine E-Mail, um sie daran zu erinnern, sich vor der Session mit den vorbereiteten Items vertraut zu machen.

5. Die Refinement-Teilnehmer prüfen die vorbereiteten Items, notieren mögliche Fragen oder Kommentare und schätzen den erforderlichen Aufwand vorab ein.

Während der Session:

1. Bestimmt einen Protokollführer für die Refinement-Session, der Notizen macht.

2. Der Product Owner legt fest, welches Item zuerst behandelt wird.

3. Das Team kann das Item kommentieren oder Fragen dazu stellen. Gibt es an dieser Stelle keine Kommentare oder Fragen, könnt ihr ohne weitere Diskussion direkt mit dem nächsten Schritt fortfahren.

4. Die Teammitglieder schätzen den Aufwand für das Item mithilfe von Planning Poker.

5. Liegen die Ergebnisse des Planning Poker innerhalb einer angemessenen Abweichung, wird der Aufwand dokumentiert und das Team fährt mit dem nächsten Item auf der Liste fort.

6. Zeigen die Ergebnisse des Planning Poker erhebliche Unterschiede bei den Aufwandsschätzungen, bespricht das Team die Faktoren, die zu den unterschiedlichen Schätzungen geführt haben. Die Ergebnisse der Diskussion werden im Ticket dokumentiert.

7. Das Team schätzt die Aufgabe erneut, bis es mit dem nächsten Item auf der Liste fortfahren kann.

Worauf sich Teams einigen müssen

Wie ihr seht, ist dieser Prozess komplexer und anspruchsvoller als der einfache Ansatz, der im vorherigen Blog beschrieben wurde. Keine Sorge: In der Praxis ist der Prozess nicht so schwierig, wie er vielleicht klingt. Dennoch müssen mehrere Schritte abgestimmt werden, und insgesamt erfordert der Prozess etwas Disziplin.

Teams müssen sich unter anderem auf Folgendes einigen:

• Wie kann der Product Owner ein Teammitglied bitten, ein Item vorzubereiten?

• Wie viel Zeit sollte für Aufgaben zur Vorbereitung des Refinements aufgewendet werden?

• Wie verhalten sich die Aufgaben zur Vorbereitung des Refinements zu den übrigen Items im Standard-Workflow (d. h. zu den vereinbarten und zugesagten Inhalten des Sprints)?

Dabei gibt es einen wichtigen Punkt: Mitgliedern eines Agile Teams sollte keine Arbeit zugewiesen werden. Sie sollten sich freiwillig dafür melden. Darf der Product Owner ein Teammitglied also direkt um Unterstützung bei der Vorbereitung des Refinements bitten?

Alternativ dazu, dass der PO die Vorbereitungsaufgabe zuweist, kann der PO das Team bitten, sie selbst zuzuweisen. In diesem Fall benötigt das Team einen Prozess, um selbst zu organisieren, welches Teammitglied über die nötige Expertise und Kapazität für die Vorbereitung verfügt. Das ist etwas schwieriger, als wenn der PO jemanden direkt um die Vorbereitung bittet, entspricht aber eher den Agile Prinzipien. Das Team sollte ausprobieren, welcher dieser beiden Ansätze für sie am besten funktioniert.

Was tun, wenn geplante und zugewiesene Vorbereitungsarbeit scheitert?

Wenn die Vorbereitung ohne Work Ticket aufgrund anderer Arbeitsverpflichtungen wiederholt scheitert, könnt ihr „Refinement Tickets“ zum Sprint Backlog hinzufügen. Dieser Ansatz gefällt mir nicht besonders, weil er einem „Spezifikations-Wasserfall“ ähnelt. Dennoch ist es ein valider Ansatz, mit dem ihr experimentieren könnt.

Wie viel Zeit reicht aus?

Das Team sollte auch den Umfang der Vorbereitung besprechen und vereinbaren. Wie viel Zeit sollte dafür aufgewendet werden?

Als Ausgangspunkt reichen für die meisten Items oft etwa 20 bis 30 Minuten Vorbereitungszeit. Selbst während der Arbeit an den zugesagten Ergebnissen des aktuellen Sprints sollten sich 20 bis 30 Minuten pro Item finden lassen.

Was bedeutet Vorbereitung eigentlich?

Die Person, die die Vorbereitung übernimmt, sollte Folgendes berücksichtigen und dokumentieren:

• Was ist das „Warum“ hinter dem Backlog Item – warum sollte das Team daran arbeiten?

• Der Nutzen des Items für die Endnutzer, falls möglich.

• Beschreibung des Backlog Items.

• Akzeptanzkriterien (3 bis 8 Akzeptanzkriterien auflisten).

• Falls das Backlog Item in kleinere Items aufgeteilt werden muss: eine Empfehlung, wie dies geschehen sollte.

• Was das Team in diesem Backlog Item nicht implementieren sollte.

Alles eine Frage der Disziplin

Diese Art der Vorbereitung auf das Backlog Refinement umfasst einige zusätzliche, fristgebundene Schritte, die vom Team einiges an Disziplin erfordern.

• Das Team muss die Vorbereitungsarbeit innerhalb weniger Tage erledigen.

• Die Teammitglieder, die am Refinement teilnehmen, müssen die Items vor der Refinement-Session lesen und berücksichtigen.

Ein guter Vorbereitungsplan fördert die nötige Disziplin

Ich empfehle Teams, einen festen Zeitplan einzuführen, der dabei hilft, die erforderliche Disziplin zu entwickeln und beizubehalten. Zum Beispiel:

• Das Backlog Refinement findet jeden Dienstagmorgen um 10 Uhr zur gleichen Zeit statt.

• Die vorbereiteten Items müssen am Montagmittag zur Prüfung bereit sein.

• Teammitglieder, die am Refinement teilnehmen, reservieren sich am Montagnachmittag eine Stunde, um sich mit den Items vertraut zu machen.

• Der Product Owner prüft die Vorbereitungsarbeit am vorherigen Mittwoch.

• Der Product Owner bestimmt bis Mittwochabend das passende Teammitglied, das das Item vorbereitet.

• Ein Teammitglied hat Donnerstag, Freitag und Montagvormittag Zeit für die 20- bis 30-minütige Vorbereitungsarbeit.

Solche Fristen zu vereinbaren und einzuhalten, ist meiner Meinung nach die einzige Möglichkeit, damit ein Vorbereitungsprozess funktioniert. Der Versuch, ad hoc etwas anderes zu vereinbaren, wird höchstwahrscheinlich scheitern.

Vorteile eines disziplinierten Vorbereitungsansatzes

Entwicklungsteams profitieren in vielerlei Hinsicht von einem disziplinierten Vorbereitungsansatz:

• Das gesamte Team kann auf die Expertise des Teammitglieds vertrauen, das das Item vorbereitet hat.

• Teammitglieder müssen nicht alles für die Item-Beschreibung oder sämtliche Akzeptanzkriterien erarbeiten.

• Das Team kann seine Aufmerksamkeit und seinen Aufwand darauf konzentrieren, die Vorbereitungsarbeit kritisch zu hinterfragen und Fragen zu stellen, um festzustellen, ob etwas übersehen wurde.

Sobald diese Praxis zur Routine wird, kann das Team die Items viel schneller durchgehen und bei unklaren Teilen der Beschreibung innehalten. Die Diskussion überspringt das Alltägliche und konzentriert sich deutlich stärker auf die wertvollen Aspekte der Arbeit.