Was kennzeichnet ein gutes Product Backlog?

Deep WatersDas Product Backlog enthält alle Arbeiten, die für die Erstellung eines erfolgreichen Produkts erforderlich sind. Es hat einen erheblichen Einfluss auf die Team-Produktivität, ob mit einem guten oder einem schlechten Product Backlog gearbeitet wird. Daher sollte sich gerade der Product Owner auch Gedanken über die Qualität des Backlogs machen. An welchen Kriterien können sich Product Owner und Team orientieren, um die Güte ihres Backlogs einschätzen zu können?

Eine Orientierung bieten die DEEP-Eigenschaften, die ein gutes Product Backlog aufweisen sollte. DEEP ist dabei ein Kürzel für:

  • Detailed appropriately
  • Emergent
  • Estimated
  • Prioritised

Betrachten wir uns diese Eigenschaften eines guten Product Backlogs einmal genauer.

Detailed appropriately

Die Grundregel hierbei heißt: Je näher ein Backlog Item an die Umsetzung heranrückt, desto granularer sollte es sein.
Dadurch gibt es im Product Backlog verschiedene Größen von User Stories:

  • Items, die im nächsten Sprint umgesetzt werden sollen, werden in detaillierter Form vorgehalten, etwa als kleine Stories.
  • Für die darauf folgenden Sprints angedachte Idems können mittelmäßig detailliert in Form von großen User Stories vorgehalten werden.
  • Noch weiter von einer Umsetzung entfernte Odems können in Form von groben Epics festgehalten werden.
  • Es wird auch deutlich, dass ein optimaler Product Backlog keinesfalls so ausschaut, dass alle Anforderungen bis ins kleinste Detail ausformuliert sind.

Emergent

Ein Product Backlog ist nie in Stein gemeißelt. Es ist lebendig und wird ständig gemeinsam von Product Owner und Team und Unterstützung der Stakeholder weiterentwickelt. Dies erfolgt z.B. im Rahmen von Backlog Grooming-Workshops, aber z.B. auch im Rahmen des Review-Meetings wird über das Backlog und mögliche Anpassungsbedarfe gesprochen.

Estimated

Das Product Backlog sollte beschätzt sein. Für die Beschätzung gibt es zahlreiche erprobte Verfahren, wie etwa das Planning Poker oder das Estimation Game. Im Rahmen von Schätzmeetings oder Backlog Grooming-Sessions kann sichergestellt werden, dass eine Beschätzung für alle Backlog-Einträge vorliegt. Für Backlog-Einträge, die noch weiter von einer Umsetzung entfernt sind, wird eine ganz grobe Schätzung vorgenommen.

Prioritised

Die geplanten Aufgaben sollten stets priorisiert sein. Die Priorisierung des Product Backlogs wird vom Product Owner vorgenommen und sichergestellt. Dabei steht er in enger Abstimmung mit den Stakeholdern und verschafft sich einen tiefen Einblick in die Marktentwicklung.

Diese grundlegenden Eigenschaften eines guten Product Backlogs geben Orientierung, worauf Product Owner und Team achten sollten. Das Product Backlog sollte außerdem gut sichtbar und einfach zugänglich sein. Ein Product Backlog Board kann hierbei eine gute Hilfe sein.

Foto: von tassoman

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Englische Version des Artikels

Das Product Backlog Board

Diese Woche habe ich mit meinem Team einmal über das Product Backlog Board nach Empfehlung von Roman Pichler gesprochen. Das Product Backlog Board ist eine Visualisierung des Product Backlogs und der wichtigsten Constraints (= Nebenbedingungen/Auflagen) im Teamraum, so dass sich jederzeit jedes Teammitglied und auch die Stakeholder darüber informieren können.
Wir haben seit einiger Zeit eine Grundversion eines Backlog Boards im Büro gehabt, nach einer Schulung von Roman in München wurden mir jedoch noch einige Punkte deutlich, die ich mit dem Team abgestimmt habe.

Der Aufbau eines Backlog Boards

Den grundlegenden Aufbau eines Backlog Boards erklärt Roman in seinem Artikel „The Product Backlog Board„. Die folgende Darstellung zeigt ein reduziertes Product Backlog Board, an dem wir uns bei unserem Board orientiert haben:

product-backlog-board

Das Product Backlog Board

Die zentralen Bereiche des Product Backlog Boards sind die Story Area und die Constraint Area.

Die Story Area

In der Story Area wird der Product Backlog der aktuell in Arbeit befindlichen Version vorgehalten. Es handelt sich dabei nicht zwangsläufig um sauber ausformulierte Userstories, auch Fehlermeldungen können dort vorgehalten werden.
Von den Stories sind dort drei verschiedene Granularitäten vorzufinden: Stories, Epics und Themes.

Fein zerteilte Stories, die fertig für eine Umsetzung sind, befinden sich oben im „ready items“-Bereich. Die feine Zergliederung und Fertigstellung von Stories werden dabei auf diejenigen fokussiert, die im nächsten Sprint für eine Umsetzung vorgesehen werden.

Im unteren Teil der Story Area befinden sich Themes und Epics. Die Themes dienen der ganz groben Unterteilung des Backlogs nach Themenbereichen. Die Epics stellen eine grobe Formulierung von Features dar, die erst dann feiner formuliert und ausgearbeitet werden, wenn die Umsetzung nahe rückt.
Im Bereich der „ready items“ ist eine Priorisierung durch den Product Owner Pflicht, während im Bereich der Themes & Epics nach Roman eine Priorisierung nicht unbedingt erforderlich ist.

Die Constraint Area

In der Constraint Area werden die grundlegenden Anforderungen an das User Interface sowie operative Eigenschaften der Software festgehalten.
Das Produkt- und User Interface-Design kann in Form von Screens/Wireframes/Skribbles mit Anmerkungen zu den wichtigsten Vorgaben Vereinbarungen dargestellt werden.
Die operativen Eigenschaften können durch „Constraint Cards“ abgebildet werden, wobei pro Karte eine bestimmte operative Eigenschaft festgehalten wird. Das kann u.a. die Browser, für die optimiert werden soll, die Performance oder die Skalierbarkeit eines Softwareprodukts betreffen.
Die Constraints sollten mit der Definition of Done verknüpft werden, damit deren Einhaltung zum Bestandteil der Abnahme von jeder einzelnen Userstory wird. Das lässt sich gut am Beispiel der Browseroptimierung verdeutlichen. Wird diese in die Definition of Done aufgenommen, ist bei der Abnahme einer Story auch eine entsprechende Prüfung in den verschiedenen Browsern vorzunehmen. Ist die Erfüllung dieses Constraints nicht gegeben, gilt die Story somit nicht als „Done“.

[Anmerkung: Roman weist in seinem Beitrag über das Product Backlog Board noch eine „Model Area“ aus. Diese wurde im Rahmen der Schulung nicht behandelt und eignet sich auch für eine spätere Ergänzung.]

Regelmäßige Backlog-Pflege

Die regelmäßige Pflege des Product Backlogs und des Boards erfolgt in Form von Backlog Grooming Workshops oder Sessions. Das Team (inkl. Product Owner) nimmt dabei gemeinsam eine Aktualisierung des Backlogs vor, bespricht Stories, zerteilt sie, fügt neue hinzu und beschätzt sie. Für Teams mit 2-wöchigen Sprints schlägt Roman vor, wöchentlich 2 Stunden mit Backlog Grooming Workshops zu verbringen.
Wir hatten bisher weniger Zeit mit dem Grooming verbracht und haben die Workshops auch nicht zu einem festen Termin durchgeführt. Dies werden wir in Zukunft tun. Der Beitrag des Teams zur Erstellung und Pflege des Backlogs wird damit deutlich höher, wodurch auch sichergestellt wird, dass alle relevanten Aspekte einer Story besprochen werden.
In dem Workshop kann das Backlog Board auch direkt aktualisiert werden.

Mit diesem Setting werden wir in den nächsten Wochen erst einmal Erfahrungen sammeln. „Inspect and Adapt“. Die Reise mit Scrum bleibt spannend.

Weitere Artikel zur Product Backlog-Pflege:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Produktmanagement Lesetipps: Überblick agiler und schlanker Methoden, die Rolle des Product Owners, 10 Tipps zur Backlogpflege, Sprint-Retrospektiven, Usertests

Diesmal mit einem Überblick über agile und „schlanke“ Methoden, Ken Schwabers Forderung nach „richtigen“ Product Owner, 10 Tipps für die Product Backlog-Pflege, kurzweilige Sprint-Retrospektiven, erfolgreiche Usertests und die 3Cs von Userstories.

  • Was hat es mit XP, Scrum und Kanban auf sich, wie unterscheiden sie sich voneinander? Bei The Agilista PM gibt es einen Überblick über agile und „schlanke“ Methoden.
  • Ken Schwaber macht sich Gedanken über die Art, wie derzeit die Rolle des Product Owners gelebt wird. Viele Produktmanager nehmen sich von der Rolle aus und lassen einen Business Analyst die entsprechenden Aufgaben erfüllen. Er sieht die Ursache darin, dass die Entwickler sich einen Product Owner wünschen, der ihnen gut vorbereitete User Stories liefert. Viel wichtiger erscheint ihm jedoch jemanden zu haben, der den Business Value richtig vorantreiben kann. Dies kann auch als Warnung an alle Product Owner gelten, die sich zu stark darauf fokussieren, den Entwicklern die richtigen Häppchen vorzuwerfen und dabei das Produkt und den Nutzen der User aus dem Auge verlieren.
  • Roman Pichler bietet in seinem Blog 10 Tipps für die Pflege von Product Backlogs, die insbesondere Scrum Product Owner lesen sollten.
  • Wenn sich nach vielen gemeinsamen Sprints Routine im Team breit macht, ist es förderlich, für Variationen im Ablauf der Sprint-Meetings zu sorgen. Eine Idee, wie sich Sprint-Retrospektiven interessanter und kurzweiliger gestalten lassen, gibt es im Projekt-Log.
  • Auf vier vergessene Prinzipien von Usertests verweist Userfocus. Bei der Beobachtung mehrerer Usertests ist David Travis auf einige Dinge gestoßen, die sich negativ auf das Ergebnis des Tests auswirken. Ein kleiner Reminder für alle, die sich mit Usertests beschäftigen.
  • Was gilt es beim Schreiben von Userstories zu beachten? Weiterhin gelten die 3Cs für Userstories von Ron Jeffries aus dem Jahr 2001: Card, Conversation und Confirmation. Ein Einstieg für Produktmanager, die sich neu mit User Stories beschäftigen.
%d Bloggern gefällt das: