Agile Methode: Product Backlog

Ein Product Backlog ist eine priorisierte Liste der gewünschten Produktfunktionalitäten. Aus Sicht der Leistungsersteller ist es eine gemeinsame Vereinbarung, welche Leistung erstellt werden soll. Die Prioritäten legen fest, in welcher Reihenfolge diese Funktionalitäten gebaut werden sollen.

Das Product Backlog enthält die Leistungsbeschreibung, die erstellt werden soll. In Scrum ist der Product Owner für die Zusammenstellung, Organisation und Koordination des Product Backlogs zuständig. Er stimmt sich mit den Stakeholdern und dem Team ab. 

Der Product Owner ist verantwortlich für das Product Backlog und er hat die letztendliche Entscheidungsgewalt darüber, was im Product Backlog steht - aber er erstellt und entwickelt das Product Backlog nicht alleine und bestimmt auch nicht exklusiv, was in ihm steht. Die Entwicklung des Product Backlog ist eine Gemeinschaftsaufgabe von Stakeholder, Auftraggebern, Entwicklern, Nutzern und anderen Menschen. Ohne die aktive Mitarbeit dieser Menschen ist der Product Owner nicht in der Lage, seine Aufgabe zu erfüllen. 

Das Product Backlog wird ständig weiter entwickelt. Es ist ein living Document. Die Leistungsbeschreibungen werden verfeinert, ergänzt, ersetzt und entfernt. Natürlich werden sie auch priorisiert, bzw. geordnet. An diesem progressiven Prozess müssen sich alle oben genannten beteiligen. - Und zwar nicht nur einmalig, sondern über den gesamten Prozess der Leistungserstellung. 

Ein Product Backlog hat nicht zwangsweise eine bestimmte Form. Insbesondere ist es nicht zwangsweise eine Sammlung von Moderationskarten auf einem White Board. - Und wer einmal versucht hat, ein Product Backlog für ein umfangreicheres Produkt auf einem Whiteboard zu erstellen, wird sehr schnell an die "Kapazitätsgrenzen" dieses Mediums gestoßen sein. Der zur Verfügung stehende Platz reicht einfach nicht aus. Ein Product Backlog kann eine Vielzahl von umfangreichen ergänzenden Dokumenten haben. Beispiel: Der Anforderer formuliert: "Ich erwarte, dass das Haus einen Dachstuhl hat." Soweit, so unklar. Es gibt mehrere Möglichkeiten mit dieser Unklarheit umzugehen. Wir können den Anforderer bitten, diese User Story so umzuformulieren, dass alle gesetzlichen Bestimmungen, bautechnischen Notwendigkeiten, statischen Voraussetzungen, etc. in der User Story genannt werden. Ich vermute, die meisten Bauherren werden damit überfordert sein. Und die meisten Whiteboards auch. Der andere Weg besteht darin einen Statiker und einen Architekten und andere Fachleute zu bitten, die Din Normen, gesetzlichen Vorschriften, etc. zusammenzustellen und von der User Story auf diese "Anhänge" zu referenzieren. Damit erhalten wir dann einfaches Product Backlog und mehrere Ordner an Unterlagen, die alle Bauvorschriften, statische Berechnungen, Architekturzeichnungen, etc. enthalten. Das Leistungserstellungsteam erhält so eine genaue Anweisung was es erstellen soll - diese ist allerdings nicht mehr "Leichtgewicht", 

Es gibt keinen bestimmten Zeitpunkt, an dem eine Weiterentwicklung des Product Backlogs erfolgt. Sowohl das Team, das die Leistungserstellung umsetzt, als auch alle anderen Beteiligten arbeiten "immer mal wieder" an dem Product Backlog. Aber bevor eine neue Timebox beginnt, müssen die zu bearbeitenden Product Backlog Items einer Definition of Ready entsprechen, damit das Team mit der Leistungserstellung beginnen kann. 

Ein Product Backlog besteht aus Product-Backlog-Elementen (Product Backlog Items, PBIs) Ein solches PBI kann eine User Story sein, soweit User Stories von den Beteiligten und insbesondere von den Leistungserstellern als ideal für die Beschreibung der Aufgabenstellung angesehen werden.

• Ein PBI kann eine Funktion sein.
• Es kann aber auch eine Änderung an einem bestehenden Produkt
• oder ein Defekt der behoben werden soll,
• oder eine technische Verbesserung,
• oder eine Wissenserweiterung sein,
• oder was auch immer von den Leistungserstellern getan werden soll.

Die Product Backlog Items müssen keine User Stories sein. Es kann auch jede anderer Form der Anforderungsbeschreibung gewählt werden. Auch wenn hier von User Stories gesprochen wird. Diese sind nur ein Beispiel für eine Vielzahl an Möglichkeiten. Hauptsache alle Beteiligten haben ein gemeinsames Verständnis.

Ein Product Backlog enthält alle funktionalen Anforderungen. Die nicht funktionalen Anforderungen können Teil des Product Backolgs sein, oder Teil der Definition of Done. Die nicht funktionalen Anforderungen müssen auf jeden Fall in einem dieser beiden Dokumente aufgeführt sein.

Das Product Backlog ist am Anfang wenig detailliert. Es entwickelt sich im Zeitverlauf in einem interaktiven Prozess der Diskussion zwischen Entwicklerteam, Product Owner und Stakeholdern. Aus einer recht oberflächlich formulierten kleinen Zahl an Anforderungen entwickelt sich mit der Zeit eine große Zahl an kleinstrukturierten detaillierten Anforderungen. In der nachfolgenden Grafik wird davon ausgegangen, dass die Backlog Elemente als User Stories formuliert sind. Das ist nicht zwingend. Jedes andere Format für die Beschreibung der Anforderungen kann ebenso gewählt werden.

Backlog Items werden mit zunehmender Zeit, durch die Gespräche zwischen Stakeholdern, Product Owner und Entwicklerteam detaillierter. Der Detaillierungsgrad wächst mit der zunehmend klareren Vorstellung der Beteiligten über das erwünschte Endergebnis des Entwicklungsprozesses.

DEEP-Kriterium für gute Product Backlogs

Für gute User Stories gibt es das INVEST-Kriterium. Für das Product Backlog wurde das DEEP-Kriterium entwickelt. DEEP bedeutet:

• Detailed aporopiately (ausreichend detailliert),
• Emergent (emergent),
• Estimated (geschätzt),
• Prioritized (priorisiert).

Detailed aporopiately (ausreichend detailliert)

Oben wurde ja bereits dargestellt, dass sich die Product Backlog Items im Zeitverlauf entwickeln. Die PBI sind nicht alle zum gleichen Zeitpunkt gleich detailliert. PBI, die in der nächsten Zeit abgearbeitet werden sollen, stehen im Product Backlog weiter oben und sind detaillierter. PBI´s, die erst zu einem späteren Zeitpunkt bearbeitet werden, können weiter unten stehen und können wesentlich unspezifischer sein. 

Es ist sinnvoll, die später zu bearbeitenden PBI zunächst unspezifisch zu lassen. Je geringer die Detailtiefe, umso geringer ist der Änderungsaufwand. Bevor mit der Bearbeitung begonnen werden kann, muss das PBI allerdings der Definition of Ready entsprechen. Vorher darf es nicht in den Sprint Backlog aufgenommen werden. Erfolgt die Aufnahme in das Sprint Backlog, bevor der Detailierungsgrad ausreichend ist, kommt es während der Leistungserstellung ständig zu Rückfragen zwischen Anforderer und Leistungserstellungsteam. Das verhindert einen effizienten Arbeitsfluss (Flow). Im schlimmsten Fall erstellt das Entwicklerteam etwas, das an den Bedürfnissen der Anforderer vorbei geht. Das kann dazu führen, dass die gesamte Arbeitsleistung eines Sprints verloren geht. Die Team Velocity wird extrem negativ beeinflusst.

Emergent (emergent)

Emergent wird hier in der Bedeutung "ständig aktualisiert und gepflegt" verwendet. Das Product Backlog soll basierend auf einem ständigen Fluss von wirtschaftlich wertvollen Informationen weiterentwickelt werden. Wenn sich Kundenwünsche, Konkurrenzverhalten, etc. verändern, muss das Product Backlog angepasst werden. Neue Elemente müssen hinzugefügt und alte ständig verfeinert werden. Die Prioritäten passen sich ständig den veränderten Verhältnissen an.

Estimated (geschätzt)

Für jedes Product Backlog Element findet eine Größenschätzung statt. Diese Schätzung spiegelt den Aufwand wieder, der notwendig ist um das Element zu entwickeln. Basierend auf dieser Schätzung und dem geschätzten Wert des Inkrements wird die Priorität und damit die Position des PBI im Product Backlog ermittelt. 

Die Schätzung erfolgt meisten in Story Points oder Idealtagen. Diese Größenschätzungen sollten relativ richtig, aber nicht extrem genau sein. Je weiter an der Spitze des Product Backlogs ein Element steht, umso weiter werden die Elemente in kleine Einheiten unterteilt und umso genauer muss auch die Schätzung werden. 

Prioritized (priorisiert)

Auch die Priorisierung der Elemente muss genauer werden, je weiter sie nach oben rücken. Die Priorisierung der Elemente, die erst nach vielen Timeboxes erarbeitet werden sollen, kann eher grob bleiben. 

Agile Methoden: Übersicht

Alle Seminarangebote 

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org