Den Backlog verantworten

Teil neun der Werkzeugkiste des Product Owners. Wir sind von der Vision bis zu kleinen Stories gekommen. Alle landen am selben Ort.

Der Product Owner, und nur der Product Owner, verwaltet den Product Backlog. Er ist dafür verantwortlich, dass der Backlog aktuell ist, und entscheidet, was gebaut wird und was nicht. Er sorgt dafür, dass die Sicht der Kunden in den Backlog einfliesst und der Backlog auf Wert ausgerichtet bleibt. Und er sorgt dafür, dass der Backlog priorisiert und aktuell ist und dass die Meetings und die Arbeit, die es dafür braucht, auch stattfinden.

Eine endlose Schleife

Einen Backlog zu verwalten hört nie auf, solange es das Produkt gibt. Es ist eine Schleife aus fünf Tätigkeiten:

1. Erfassen: alle Bedürfnisse und Wünsche sammeln, die Stakeholder ans Produkt haben.
2. Priorisieren: die gesammelten Einträge nach erwartetem Wert ordnen.
3. Verfeinern und schätzen: die obersten Einträge auf den Detailgrad bringen, den es zum Bauen braucht. Das passiert mit dem Team, und das Team entscheidet, wie viel Detail und Kontext alle brauchen, um einen Eintrag zu verstehen.
4. Planen und koordinieren: den Backlog aktuell halten, während gearbeitet wird, am besten mit einer Story Map oder einer Roadmap. Die müssen ebenfalls aktuell bleiben.
5. Überprüfen: in regelmässigen Abständen den Wert, den du von den gebauten Einträgen erwartet hast, mit dem Wert vergleichen, den sie tatsächlich gebracht haben. Den Unterschied in den Backlog zurückspielen. Dafür sind die Sprint Reviews mit den Stakeholdern da.

Schritt fünf wird übersprungen. Ohne ihn ist der Backlog eine Liste von Dingen, die zu tun sind, statt einer Liste von Wetten, die du überprüfst.

Eine Liste für alles

Ein Backlog enthält mehr als Stories. Es gibt vier Arten von Einträgen:

• Bugs
• Enabler: technische oder architektonische Arbeit, die spätere Stories brauchen
• Stories
• Technische Schulden

Alle vier kommen in dieselbe Liste und werden gegeneinander priorisiert. Alle stehen dort, weil sie dem Produkt und damit den Kunden einen Wert bringen.

Die übliche Alternative ist eine separate Liste für technische Schulden, die das Team nebenher führt. Diese Liste wird nie gegen etwas priorisiert und deshalb nie abgearbeitet, bis die Schulden zu einem Ausfall werden und sich von selbst nach vorne drängeln.

Eine Methode wählen und dabei bleiben

Es gibt viele Wege, einen Backlog nach Wert zu ordnen:

• Wert gegen Kosten: die einfachste. Beides auftragen und oben links anfangen.
• Buy a Feature: das Spiel von Luke Hohmann. Die Stakeholder bekommen ein Budget aus Spielgeld und kaufen die Features, die sie am meisten wollen.
• WSJF (Weighted Shortest Job First): aus der Arbeit von Don Reinertsen, bekannt geworden durch SAFe. Verzögerungskosten geteilt durch die Grösse der Arbeit.
• Kano-Modell: die Unterscheidung von Noriaki Kano zwischen Basismerkmalen, Leistungsmerkmalen und Begeisterungsmerkmalen.

Welche am besten passt, hängt vom Kontext ab. Wichtiger ist, eine Methode konsequent für jeden Eintrag zu nutzen. Ein Backlog, der am Montag nach WSJF und am Donnerstag nach dem Lautesten priorisiert wird, ist nicht priorisiert.

Priority Poker

Die Methode, die ich am liebsten in Management-Meetings sehen würde, ist Priority Poker. Es funktioniert wie Planning Poker, schätzt aber die Priorität statt des Aufwands.

Alle Teilnehmenden bekommen ein Kartenset mit Werten, die ungefähr wie die Fibonacci-Folge wachsen, zum Beispiel 100, 200, 300, 500, 800, 1300, 2100 und 3400. Ein Eintrag bekommt vorab eine Priorität als Referenz. Dann läuft es für jeden Eintrag so:

1. Jemand stellt den Eintrag vor.
2. Alle wählen verdeckt eine Karte, und alle Karten werden gleichzeitig aufgedeckt.
3. Wer die höchste und wer die tiefste Karte hat, erklärt, warum.
4. Alle wählen noch einmal verdeckt, und die Karten werden wieder aufgedeckt.
5. Die Gruppe einigt sich auf einen Wert.

Die Schätzungen sind relativ: Jeder Eintrag wird mit den bereits eingeordneten verglichen. Eine Moderatorin achtet auf die Timebox und hält die Diskussion lösungsorientiert.

Der Wert liegt im sozialen Teil. Die Leute im Raum sind von der Entscheidung nicht nur betroffen, sie sind daran beteiligt. Die höchste und die tiefste Karte bringen verstecktes Wissen auf den Tisch: die Teamleiterin, die weiss, dass ein Feature in der Praxis nutzlos ist, oder den Entwickler, der weiss, dass eine kleine Änderung drei andere möglich macht. Das Ergebnis ist eine Rangliste, an der alle mitgebaut haben und die deshalb alle mittragen.

Das gilt auch fürs Management. Führungskräfte spielen selbst mit und können niemanden an ihrer Stelle schicken. Mach es regelmässig, damit geänderte Prioritäten rechtzeitig im Backlog ankommen, statt zu Feuerwehrübungen zu werden. Es funktioniert auch über mehrere Ebenen: Die Prioritäten einer Ebene setzen die Ziele der Ebene darunter.

Das Ferientool nach Release 1

Release 1 ist draussen. Das kam danach herein, nach einer Runde Priority Poker mit HR, zwei Teamleitenden und dem Team:

Eintrag	Art	Priorität
Guthaben ist falsch bei Anträgen über Neujahr	Bug	3400
Halbe Tage	Story	2100
Automatisierte Tests für die Guthabenberechnung	Technische Schulden	2100
Unterbesetzte Wochen markieren	Story	1300
Krankheit	Story	800
Bewilligung im Team-Chat	Story	300

Zwei Beobachtungen. Der Bug hat gewonnen, weil HR erklärt hat, dass er im Dezember alle betrifft. Und die Tests landeten auf derselben Priorität wie halbe Tage, weil der Entwickler erklärt hat, dass der Neujahrs-Bug entstanden ist, weil niemand die Guthabenberechnung gefahrlos ändern konnte. Allein hätte niemand die Tests so hoch eingestuft.

Als Nächstes

Der letzte Teil der Serie behandelt die beiden Checklisten an den Enden des Sprints: die Definition of Ready und die Definition of Done.