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

Werbeanzeigen

Tipps zur Priorisierung des Product Backlogs von Mike Cohn

Product Backlog PriorisierungEine echte Perle zum Thema Priorisierung des Product Backlogs habe ich kürzlich bei Axel Heinz gefunden. Es handelt sich dabei um einen Vortrag von Mike Cohn (ich habe hier schon über sein Buch „User Stories Applied“ geschrieben). In diesem Vortrag stellt er nach einer Einführung in das Thema und dessen Bedeutung die vier Ansätze für die Priorisierung des Backlogs vor: Kano-Analyse, Theme-Screening, Theme-Scoring und relative Gewichtung.

Die Bedeutung guter Backlog-Pflege

Mike Cohn betont zunächst noch einmal die Bedeutung der Pflege des Backlogs. Er konnte in der Praxis zahlreiche Teams beobachten und die richtig guten Teams zeichneten sich alle dadurch aus, dass sie rund 10% ihrer Zeit in die Pflege des Product Backlogs stecken und diesen aktiv pflegen.
Das Stichwort lautet hier Backlog Grooming und kann zum Beispiel in Form von Workshops mit dem ganzen Team erfolgen.
Mike Cohn betont, dass es für Entscheidungen in der Backlog Priorisierung immer eine solide Grundlage geben sollte, wie etwa die Ergebnisse von Umfragen, aus Statistiken oder ähnliches. Statistisch signifikant braucht es für ihn nicht zu sein, aber z.B. das Feedback von 20-30 Anwendern im Rahmen einer Umfrage kann schon viel aussagen.
Nun aber zu den vier Maßnahmen, die er im folgenden vorstellt.

Kano-Analyse

Bei der Kano-Analyse wird eine Befragung von Anwendern durchgeführt, durch die eine Klassifizierung von Funktionalitäten in verschiedene Kategorien möglich ist:

  • Basisfaktoren: Basisfaktoren werden von den Anwendern als selbstverständlich vorausgesetzt. Werden sie erfüllt, entsteht keine Zufriedenheit, bei Nichterfüllung entsteht jedoch Unzufriedenheit.
  • Leistungsfaktoren: Diese wirken linear und ein mehr von dieser Funktionalität führt zu mehr Zufriedenheit der Anwender.
  • Begeisterungsfaktoren: Begeisterungsfaktoren werden vom Anwender so nicht erwartet, sie überraschen ihn positiv. Als Beispiel nennt Mike Cohn einen Dosenhalter im Auto, den seine Frau spitze fand, der 1993 noch keineswegs selbstverständlich war. So etwas kann sogar das „Zünglein an der Waage“ für eine Kaufentscheidung sein.

Manchmal ist es gerechtfertigt, darüber Schätzungen abzugeben, in welche Kategorie eine Funktionalität fällt. Noch sinnvoller ist meist jedoch die Befragung einer kleinen Gruppe von Anwendern, etwa 20-30 Stück.
Als Tipp für die Einplanung in das Produkt schlägt er vor, dass alle Basisfaktoren integriert werden, da sonst mit Unzufriedenheit gerechnet werden muss. Darüber hinaus sollten einige lineare Funktionalitäten und wenigstens ein paar Begeisterungsfaktoren eingeplant werden.

Weitere Informationsquellen für das Kano-Modell:

Theme-Screening

Das Vorgehen beim Theme-Screening erfolgt mit den folgenden Schritten:

  1. Identifiziere als erstes die Faktoren, die für die Priorisierung als Kriterien für das nächste Release herangezogen werden sollen. Zum Beispiel die Bedeutung für die bestehenden Anwender oder die Generierung von Umsatz. Diese Kriterien werden als Reihen in eine Tabelle eingetragen. Es sollten etwa 5-9 Kriterien sein.
  2. Nach der Festlegung der Priorisierungskriterien wird ein „baseline theme“ gewählt. Eine Story oder ein Theme, die im weiteren Vergleich als Basis für die relative Bewertung genutzt wird. Dafür eignen sich solche, die wahrscheinlich in das nächste Release aufgenommen werden und das allen Teammitgliedern vertraut und verständlich ist. Es sollte aber nicht das wichtigste Theme sein, da in diesem Fall alle weiteren Themes im Verhältnis schlechter abschneiden würden. Das gilt also analog zu Referenz-Stories beim relativen Beschätzen des Product Backlogs, wo meist eine mittelgroße oder eine eher kleinere Story als Vergleich genutzt wird.
  3. Alle Themes oder Stories, die zur Auswahl stehen, werden nun im Vergleich zum „baseline theme“ nach allen Kriterien bewertet. Für die schlechter abschneidenden Themes wird jeweils ein – eingetragen, für die besser abschneidenden ein + und für die gleich zu bewertenden Themes eine Null.

Mike Cohn stellt auf seiner Website sogar ein kleines Tool zum Theme-Screening bereit, das auch schnell das Vorgehen beim Theme-Screening verdeutlicht.

Weitere Informationsquellen für das Theme-Screening:

Theme-Scoring

Theme-Scoring ist dem Theme-Screening sehr ähnlich. Auch hier geht es darum, verschiedene Themes gegeneinander abzuwägen. Als erstes werden auch hier die verschiedenen Kriterien zusammengestellt, nach denen die Bewertung erfolgen soll. Dann ist eine Bewertung der Kriterien erforderlich. Dafür erhalten sie einen Prozentwert, der sich zu 100% aufsummiert.

Als nächstes werden wieder alle Themes nebeneinander gestellt. Dann wird die Erfüllung der Kriterien für alle Themes bewertet auf einer Skala von 1-5, wobei 1 für eine schlechte Erfüllung des Kriteriums und 5 für eine gute Erfüllung des Kriteriums steht. Dabei ist es hilfreich, als erstes für alle Kriterien ein Basis-Theme festzulegen, dass eine Bewertung von 3 erhält. Somit lassen sich die anderen Themes leichter im Verhältnis zum jeweiligen Basis-Theme bewerten.

Mike Cohn stellt auf seiner Website auch ein kleines Tool zum Theme-Scoring bereit.

relative Gewichtung

Die relative Gewichtung („relative weighting“) ist ein Priorisierungsansatz, bei dem sowohl die positive Auswirkung der Präsenz eines Features als auch die negative Auswirkung der Abwesenheit eines Features in die Beurteilung einbezogen wird. Für jede Funktionalität wird eine bewertung von 0 (gering) bis 9 (hoch) vorgenommen.

Die Themes werden dabei in die Reihen einer Tabelle eingetragen. Dann wird jeweils eine Bewertung für den Nutzen der Funktion bei Bestehen und der Strafe bei Abwesenheit hinterlegt. Zusätzlich wird noch ein Wert für den geschätzten Aufwand, etwa in Story Points oder auch einem Euro-Betrag, hinterlegt. Es werden also in diesem Fall die Kosten einer Funktionalität explizit mit berücksichtigt.
Es wird dann geschaut, welchen Anteil am Gesamtnutzen und welchen Anteil an den Gesamtkosten eine bestimmte Funktionalität hat. Diese beiden Werte werden durcheinander geteilt und es ergibt sich eine Priorisierungskennzahl.

Anteil am Gesamtnutzen Anteil an den Gesamtkosten Priorisierung
57% 67% 0.85
43% 33% 1.30

Das als zweites in diesem Fall aufgeführte Feature bringt zwar einen geringeren Nutzen, ist aber ein ganzes Stück günstiger. Dadurch ist der Return on Investment (ROI) von letzterem größer.

Auf der Website Mike Cohn gibt es auch zur relativen Gewichtung ein kleines Tool.

Links zum Vortrag von Mike Cohn

Der Vortrag von Mike Cohn
Folien von Mike Cohn (PDF)

An dieser Stelle möchte ich auch noch auf eine Excel-Vorlage für die Product Backlog Priorisierung von Michael Romer hinweisen.

Foto: peterstev
——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-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.
%d Bloggern gefällt das: