Was kennzeichnet ein gutes Product Backlog?

20. Dezember 2011 2 Kommentare

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 Facebook, Twitter, E-Mail (oben rechts) oderRSS-Feed.

Englische Version des Artikels

About these ads

Gespeichert unter Effektivität und Effizienz, Methoden, Scrum Getaggt mit , , , , , , , , , , , , , , , , ,

Tipps zur Priorisierung des Product Backlogs von Mike Cohn

24. November 2011 4 Kommentare

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

Gespeichert unter Methoden, Scrum Getaggt mit , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Wie schreibe ich eine User Story?

26. September 2011 3 Kommentare

User Stories scheinen sich zu einer “State of the art”-Methode zur Formulierung von Anforderungen entwickelt zu haben. Kaum ein Buch über agile Softwareentwicklung, dass nicht auf diese Form der Beschreibung von Anforderungen verweist. Aber: Wie schreibt man eigentlich eine User Story?
Erst einmal zur Beruhigung: User Stories schreiben ist wie Fahrad fahren! Am Anfang ist es ungewohnt und fühlt sich seltsam an. Nach ein paar Versuchen läuft es dann aber wie von alleine und man verlernt es nie!

Nach über einem Jahr der Arbeit mit User Stories kann ich mir kaum noch vorstellen, wie ich mit meinen Teams vorher Anforderungen formuliert habe.

Grundsatz: Formulierung aus Sicht des Nutzers

Ein wichtiger Grundsatz bei User Stories ist, dass sie aus der Sicht eines Anwenders geschrieben werden. Daher werden sie auch frei von technischem Schnickschnack gehalten. Jeder, der am Projekt beteiligt ist, also auch jeder Anwender, sollte sie optimalerweise verstehen können. Hingegen sollte das Entwicklungsteam tolerant gegenüber der Fachsprache der Anwender sein.

3 Bestandteile einer User Story

Eine User Story setzt sich mindestens aus den folgenden drei Elementen zusammen:

  • Einem kurzen, prägnanten Namen.
  • Einer kurzen Beschreibung der Anforderung.
  • Mehreren Akzeptanzkriterien, die die Details ausdrücken und dokumentieren und bei der Klärung helfen, ob eine Story wirklich abgeschlossen ist.

Nach wie vor hilft diese einfache Satzkonstruktion beim Einstieg in das Schreiben einer User Story:

Um (den folgenden Nutzen zu erhalten), möchte ich als (Anwendertyp) (diese Funktion).

Schauen wir uns die drei Teile dieses Satzes noch einmal etwas genauer an.

Name

Eine kurze, prägnante Benennung, die sich die Teammitglieder und die anderen Beteiligten gut merken können. Am besten ist sie so, dass jeder etwas damit anfangen kann, wenn jemand sagt “Wir sollten noch xy umsetzen”. Wir die Anmeldung an einem System kann also die Bezeichnung “Anmeldung” ausreichend sein, wenn das Team versteht, was damit gemeint ist.

Beschreibung

Wer möchte eigentlich etwas?

Es ist möglichst klar darzustellen, von wem die Anforderung überhaupt kommt. Vermutlich am häufigsten anzutreffen sind User Stories mit dem Anwendertyp “Benutzer”. Es kann jedoch deutlich spezifischer zum Ausdruck gebraucht werden, um welchen Benutzer es sich handelt. Z.B. durch eine Ergänzung wie “als Benutzer mit einem Twitter-Account”. Das ist schon ein ganzes Stück spezifischer und hilft allen Beteiligten einzuschätzen, wie groß die Nutzergruppe ist und woher ihr Wunsch kommt.
Wenn das Team mit Personas arbeitet, kann es sinnvoll sein, die bestimmte Persona zu nennen, die im besonderen diese Anforderung hegt.

Warum will er das tun, welchen Nutzen will er erzielen?

An dieser Stelle steht der zu Grunde liegende Nutzen, der erreicht werden soll. Die Idee ist dabei, dass die anschließend beschriebene Funktionalität aus dem Nutzenstreben abgeleitet sein muss. Ein Benutzer will sich z.B. nicht als Selbstzweck bei einer Softwareanwendung anmelden, sondern macht diese nur, um die Kernfunktionen der Software anschließend nutzen zu können.

Durch welche Funktionalität will er den Nutzen realisieren?

In diesem Teil wird dargelegt, welche Funktionalität zur Realisierung des Nutzens implementiert werden soll.

Insgesamt könnte die Beschreibung einer User Story damit wie folgt aussehen:

Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten anmelden).

User Stories können einen sehr unterschiedlichen Grad an Genauigkeit annehmen. Dies hängt auch damit zusammen, wie nah oder weit die Umsetzung der Anforderung ist. Es kann sein, dass die Lösung der User Story noch weitgehend offen gehalten werden soll, oder aber es ist schon eine Entscheidung für eine konkretere Umsetzungsvariante gefallen. Wurde etwa bereits festgelegt, dass in unserer Beispiel-Story die Anmeldung per Twitter-Zugangsdaten mit Hilfe des Protokolls OAuth erfolgen soll, könnte die User Story wie folgt konkretisiert werden:

Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten über das sichere Authorisierungsprotokol OAuth anmelden).

Akzeptanzkriterien

Wie kann festgestellt werden, ob die User Story entsprechend den Anforderungen umgesetzt wurde? Die Akzeptanzkriterien spielen dabei eine besondere Rolle. Sie beantworten die Frage, was getestet werden soll. Eine gute Hilfsregel für die Formulierung von Akzeptanzkriterien ist, dass sie mit “Teste…” anfangen sollten. Beispiele für unsere obige Story könnten sein:

  • Teste die Eingabe eines ungültigen Benutzernamens…
  • Teste die Eingabe eines ungültigen Passworts
  • Teste die Eingabe eines gültigen Benutzernamens und eines gültigen Passworts
  • …

Wie stelle ich sicher, dass das Team die User Stories versteht?

Zunächst kann eine gewisse Unsicherheit vorhanden sein, ob das Entwicklungsteam die User Stories in der Form akzeptiert. Hier ist es aber wie mit vielen anderen Dingen in der agilen Softwareentwicklung. Es gehört Mut dazu, Dinge auszuprobieren und sich einzugestehen, dass am Anfang nicht alles rund läuft. Inspect and adapt. Nach ein paar Wochen der Arbeit mit User Stories haben dann alle Beteiligten eine gemeinsame Vorstellung davon entwickelt, wie umfangreich, detailiert und sauber die User Stories ausgearbeitet werden müssen. Das funktioniert am besten, wenn darüber hinaus regelmäßige Backlog Grooming-Sitzungen durchgeführt werden, in denen mit dem Entwicklungsteam und Anwendern zusammen an den Stories gearbeitet wird.

Ergänzende Beschreibungen, Mock-ups, Wireframes,…

Ergänzt werden können diese drei Grundelemente einer User Story durch weitere Informationen, die dem Entwicklungsteam dabei helfen zu verstehen, wie die Umsetzung erfolgen soll. Das können ergänzende Beschreibungen, Mock-ups, Wireframes, Scribbles … you name it … sein. Das wichtigste ist, dass diese das gemeinsame Verständnis der Anforderung unterstützen. Sie sollten aber niemals die persönliche Kommunikation zwischen den Beteiligten ersetzen!

Weiterführende Informationen:

Foto: kmlz

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Gespeichert unter Methoden, Scrum Getaggt mit , , , , , , , , , , , , , , , , , , , , ,

Userstories: Volle Konzentration auf den Kundennutzen

25. Mai 2011 2 Kommentare

Ein zentraler Vorteil der Verwendung von Userstories für die Beschreibung von Anforderungen ist es, den Kundennutzen stark in den Vordergrund zu stellen. Wofür wird eine Funktion eigentlich entwickelt? Das sollte allen Beteiligten stets präsent sein.

Ein weiterer Vorteil von Userstories ist, dass Stories schreiben eine Übungssache ist und sich von jeder Person erlernen lässt. Vereinfacht wird der Einstieg in das Schreiben von Userstories durch Vorlagen für den Satzbau.
Bisher habe ich meist diese sehr gebräuchliche und verbreitete Vorlage für das Schreiben von Nutzerstories verwendet:

Als (Anwendertyp) möchte ich (folgende Aktion durchführen), um (dieses Ziel zu erreichen).

Für diesen Aufbau einer Userstory finden sich verschiedene Referenzen. Ich habe auch sehr gute Erfahrungen damit gemacht. Der große Fortschritt gegenüber vorher von uns verwendeten Arten der Anforderungsbeschreibung ist u.a. darin zu sehen, dass die Stories für jeden verständlich sind und der Kundennutzen klar ausgedrückt werden muss.

Aus einem Gespräch mit einem Kollegen und ScrumMaster habe ich lernen dürfen, dass eine leichte Modifikation des Aufbaus der Userstory dabei hilft, den Kundennutzen noch stärker in den Fokus zu rücken. Das sieht dann wie folgt aus:

Um (den folgenden Nutzen zu erhalten), möchte ich als (Anwendertyp) (diese Funktion).

Den Fokus auf den Kundennutzen zu richten ist wichtig und richtig. Daher werde ich zukünftig auch diese Vorlage verwenden.

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

Foto: CannedTuna

Gespeichert unter Methoden, Scrum Getaggt mit , , , , , , , , , , ,

Follow

Bekomme jeden neuen Artikel in deinen Posteingang.

Schließe dich 915 Followern an

%d Bloggern gefällt das: