Priorisierung Im Product Backlog

Transkript

1 Priorisierung Im Product Backlog Praktische Tipps zur sofortigen Anwendung Author: Oliver Mann, Role: Agile Coach / Business Prowareness Contact: o.mann@prowareness.de,

2 Priorisierung im Product Backlog Praxiserprobte Tipps zur sofortigen Anwendung Einleitung Eines der wichtigsten Artefakte in Scrum ist das Product Backlog. Das Product Backlog gehört dem Product Owner und enthält eine geordnete Auflistung von allem, das für das Produkt benötigt wird. Es ist dynamisch und verändert sich fortlaufend, um Anforderungen zu identifizieren, mit denen ein Produkt realisiert und optimiert werden kann, um wettbewerbsfähig und nützlich zu sein. Der Scrum Guide von scrum.org sagt einiges dazu, WAS ein Scrum Team mit dem Product Backlog tun sollte, um sicherzustellen, dass mit jedem Sprint die wertvollsten Features geliefert werden. Was er uns nicht verrät, sind Details über das WIE ein solches Backlog strukturiert und priorisiert wird, damit es in der täglichen Arbeit übersichtlich, transparent und für jeden verständlich bleibt. Steht einmal eine durchdachte Backlog Struktur, kommt der Priorisierung aller Einträge im Product Backlog eine zentrale Bedeutung zu. Dieses Whitepaper enthält einige Tipps und Beispiele, wie die Einträge eines Product Backlogs priorisiert werden können. Es ist nützlich für alle, die ein Product Backlog anlegen und pflegen sowie Anregungen suchen, um sich die Arbeit leichter zu machen. Was ist ein Product Backlog? OLIVER MANN Agile Coach / Business Consultant Oliver ist Agilist aus Leidenschaft und begeisternder Moderator mit umfassendem Fachwissen. Der Berliner mit Wohnsitz in München hat in den vergangenen 20 Jahren in verschiedenen Unternehmen und Teams als Projekt- und Senior Produktmanager gearbeitet. Dabei hat sich immer mehr seine Passion für Scrum herauskristallisiert. Oliver tauscht gern sein Wissen als Produktmanager, Product Owner und Conversion Profi aus, um Produkte und Services zu realisieren, die Sie begeistern und Ihre Kunden schlichtweg lieben! Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die Änderungen an dem Produkt in zukünftigen Releases ausmachen. (aus dem Scrum Guide) Ein Product Backlog ist also vereinfacht ausgedrückt nichts anderes, als eine Liste verschiedenartiger Einträge zu einem Produkt, die in eine Reihenfolge gebracht werden. Es liegt in der Verantwortung des Product Owners, die Einträge im Backlog sinnvoll anzuordnen und zwar so, dass das Entwickler-Team in folgenden Sprints stets den höchstmöglichen Wert liefern kann. 2

3 Was ist ein Backlog Item? Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert. (Scrum Guide) Um das Product Backlog homogen und verständlich zu halten, benötigt jeder Eintrag mindestens eine Beschreibung sowie die oben erwähnten zusätzlichen Attribute. Mit Schätzung ist die Aufwandsschätzung (Estimation) des Teams zur Umsetzung eines Backlog Eintrags gemeint. Den Wert (Value) eines Eintrages legt der Product Owner fest. Dies kann er allein tun, meist aber in Abstimmung mit den Stakeholdern und den Informationen aus dem Team. Die Reihenfolge von Einträgen im Product Backlog kann sich so aus Höhe der Schätzung und dem Wert ergeben. Beispiel Eintrag 1: Schätzung: 9 Wert: 2 Eintrag 2: Schätzung: 2 Wert: 9 Der Product Owner wird Eintrag 2 höher priorisieren, da der Aufwand für die Umsetzung im Vergleich zu Eintrag 1 gering ist und der Business Value hoch. Product Backlog im Scrum Workflow Zentraler Ausgangspunkt für die Entwicklungsaktivitäten ist ein gut organisiertes Product Backlog. Hoch priorisierte Einträge werden vom Product Owner ausgewählt, um diese im Sprint-Planungs-Meeting (Sprint Planning) mit dem Developer Team zu besprechen, das Sprint Ziel zu erarbeiten sowie ein Commitment zu erhalten, welche Items im nächsten Sprint vom Team als Done umgesetzt werden. Stories, Epics, Themes & Defects Wie oben erwähnt können Backlog Einträge erst dann in eine sinnvolle Reihenfolge gebracht werden, wenn wesentliche Informationen vorliegen. Ist ein Eintrag klar beschrieben und mit detaillierten Informationen versehen, steht er weiter oben im Backlog. Liegen nicht alle Informationen vor, steht der Eintrag weiter unten im Product Backlog. Obere Einträge kommen tendentiell für eine Umsetzung in der nächsten Iteration in Frage. Weiter unten stehende müssen konkretisiert werden, um in der Rangfolge nach oben zu steigen. 3

4 Scrum spricht pauschal von Backlog Einträgen (Items). Hilfreicher für das Verständnis und die Organisation des Product Backlogs ist eine Differenzierung, wie sie aus dem extreme Programming (XP) bekannt ist. Backlog-Einträge können sein: User-Stories: Eine User-Story beschreibt eine Funktion aus der Perspektive eines Anwenders der diese Funktionalität benötigt. Sie sollte klein genug sein, um in einem Sprint umgesetzt zu werden und wird gern nach dem Pattern Als <Nutzer-Rolle> möchte ich <Ziel/Wunsch>, so dass ich <Nutzen/Wert> formuliert. Epics: Ein Epic ist gewissermaßen eine zu große User-Story. Es ist ein Label für eine Idee oder Funktion, die noch zu unkonkret oder komplex für die Umsetzung in einem Sprint ist. Epics werden in kleinere User-Stories heruntergebrochen. Themes: Themes stellen eine Gruppe von User-Stories dar. Dies kann hilfreich sein, um gleiche Stories einer Domäne zusammenzufassen oder für entsprechende Releases. Defects: Defects sind weniger neue Features, als vielmehr eine Verbesserung bestehender oder beheben gar größere Probleme. Sie können ebenso Items eines Backlogs darstellen und entsprechend geschätzt und priorisiert werden. Struktur eines Product Backlogs Die Priorität von Einträgen im Product Backlog nimmt nach unten hin ab. Ganz oben stehen die wichtigsten Einträge, die konkret genug und klein genug für eine Umsetzung im Sprint sind: die User-Stories Weiter unten stehen Einträge mit geringerer Priorität oder höherer Komplexität, die erst für nächste Sprints in Frage kommen oder zu groß sind, um in einem Sprint umgesetzt zu werden: Epics Ein einfaches Product Backlog das sich an obiger Struktur orientiert kann etwa so aussehen. Das Product Backlog besteht aus 9 Stories und 2 Epics (durch Fettung hervorgehoben). Die Minimal-Anforderungen zur Organisation eines Backlogs sind erfüllt: Es ist sortiert und jeder Eintrag hat eine Beschreibung, Schätzung sowie einen zugeordneten Wert. 4

5 Bedeutung guter Backlog Priorisierung Scrum verfolgt das Ziel, Produkte durch inkrementelle Auslieferung nutzbar zu machen und so frühzeitig Feedback für die weitere Entwicklung zu erhalten. Je früher grundlegende Features fertig sind, desto eher ist das Produkt auslieferbar und einsatzbereit. Ein gut organisiertes und priorisiertes Product Backlog ist ein entscheidender Erfolgsfaktor in der agilen Produktentwicklung. Priorisierungsentscheidungen sollten immer eine solide Grundlage haben, etwa aus Anwender-Tests, Umfragen, Statistiken und ähnlichem. Dabei geht es nicht um einen streng wissenschaftlichen Ansatz von größter Genauigkeit, aber einen empirischen, der Feedback zum Produkt systematisch und auswertbar einholt. Priorisierung nach MoSCoW Bei umfangreicheren Product Backlogs ist nicht immer klar, wie sich die Rangfolge der Items genau zusammensetzt und ob diese tatsächlich wertschöpfend ist. Es kommen Fragen auf wie: Welchem Backlog Eintrag ist der Vorzug zu geben, wenn diese identische Schätzungen und Werte aufweisen? Werden Epics mit hohem Business Value wichtiger als Stories mit geringem? Wie bewerte ich funktionale gegenüber nicht funktionalen Anforderungen? Eine einfache Orientierung zur leichteren Priorisierung kann das MoSCoW Schema aus dem Projektmanagement bieten. Einträge werden danach klassifiziert, ob sie M -MUST Haves sind (unbedingt für die Umsetzung erforderlich) S - SHOULD have (umsetzen, wenn alle Must have s erledigt sind) C - COULD have (kann umgesetzt werden, wenn höherwertige Anforderungen nicht beeinträchtigt werden) W - WON T have (wird nicht umgesetzt, evtl. für spätere Umsetzungen interessant) Wenn Sie zum Beispiel ein Softwareprojekt beginnen und die techn. Umgebung benötigen um loszulegen (etwa Server, Entwicklungs- und Testsysteme) ergeben sich lineare Abhängigkeiten, die als MUST-Kriterien erfüllt sein müssen, bevor ein Team Features liefern kann. Kano-Analyse Bei der Kano-Analyse wird eine Befragung von Anwendern durchgeführt, durch die eine Klassifizierung von Funktionalitäten eines Produktes in verschiedene Kategorien möglich ist: Basisfaktoren: Basisfaktoren setzen die Anwender als selbstverständlich voraus, sie sind unbedingt erforderlich. Sind solche Funktionen enthalten, entsteht zwar keine Zufriedenheit. Fehlen sie aber, kann Unzufriedenheit entstehen. Zum Beispiel wenn eine Webseite keine Suche aufweist. Leistungsfaktoren: Diese wirken linear. Je mehr dieser Faktoren ein Produkt enthält, desto mehr Zufriedenheit kann erzielt werden. Leistungsfaktoren können ebenso Unzufriedenheit bei einem Produkt beseitigen. Zum Beispiel kostenlose Versionsupdates eines Betriebssystems statt kostenpflichtiger. Begeisterungsfaktoren: Begeisterungsfaktoren sind Funktionen, die der Anwender so nicht erwartet, sie überraschen ihn in höchst positivem Maß. Sie sind das Tüpfelchen auf dem i und oft die abgrenzenden Merkmale zum Wettbewerb. Das hochwertige Material von Apple s Macbooks zum Beispiel und ihr besonderes Design. 5

6 Abbildung: Das Kano-Modell in seiner Grundfassung Um belastbare Ergebnisse zu erzielen, sollten Sie mehr als nur ein paar Anwender befragen. Gruppen aus Teilnehmern liefern gute Ergebnisse und können zum Beispiel auch online befragt werden. Die Ergebnisse aus der Kano-Analyse helfen auch im Hinblick auf Releases, Funktionen zur richtigen Zeit zu liefern. Die Basisfaktoren gelten als Pflicht und sollten zuerst geliefert werden, da Sie sonst potentielle Unzufriedenheit beim Nutzer generieren. Leistungsfaktoren steigern die Zufriedenheit und sind zum Beispiel hilfreich für die Produktvermarktung. Ergänzen Sie Ihr Produkt später immer mal um Begeisterungsfaktoren, um innovativ zu bleiben und sich vom Wettbewerb zu differenzieren. Mehr zum Kano Modell bei Wikipedia Theme Screening Theme Screening ist eine leicht verständliche und hilfreiche Priorisierungstechnik um Themes (Gruppen von User-Stories) oder Epics gegeneinander zu bewerten. Im größeren Rahmen lassen sich ebenso verschiedene Projekte oder Produkte priorisieren. In diesen Schritten wird vorgegangen: 1. Zuerst werden die Faktoren identifiziert, die für die Priorisierung des nächsten Releases als Kriterien herangezogen werden sollen. Etwa die Bedeutung für die Anwender, inwieweit sich neue Kunden gewinnen lassen oder oder wie viel Umsatz ein Feature einbringen wird. Fünf bis neun solcher Kriterien werden als Reihen in eine Tabelle eingetragen. 2. Nun wird ein sogenanntes Baseline Theme gewählt, das im weiteren Vergleich als Basis zur relativen Bewertung dient. Dafür eignen sich Stories oder Themes, die für das kommende Release vorgemerkt sind und den Mitgliedern des Teams bekannt und für jeden verständlich sind. Wählen Sie nicht das wichtigste Theme aus, da alle weiteren Themes im Verhältnis sonst schlechter abschneiden. 3. Alle ausgewählten Themes oder Stories werden nun im Vergleich zum Baseline Theme nach allen Kriterien bewertet. Schlechter abschneidende Themes erhalten ein Minus, besser abschneidende ein Plus. Eine Null wird eingetragen, wenn Kriterien eines Themes gleich bewertet werden. 6

7 Die Plus-Wertungen werden abschließend aufsummiert, die Minus-Wertungen abgezogen. Ist das für alle Themes erledigt, können sie entsprechend ihrer Punktzahl in eine priorisierte Reihenfolge gebracht werden. Das Beispiel zeigt die Priorisierung von vier Themes anhand von fünf Kriterien. Mehr Informationen zum Theme Screening bei Mike Cohn Priorisierung nach Relative Weight Die Priorisierung nach relativer Gewichtung eignet sich für umfangreichere Product Backlogs und ist aus verschiedenen Gründen sehr hilfreich: Es fließen mehrere Kriterien in die Beurteilung zur Wichtigkeit eines Eintrages ein Alle Kriterien werden systemisch gleich bewertet Unterschiedliche Einträge (Epics, Stories, Themes, NFRs) können bewertet werden Jeder Eintrag erhält eine Prioritätszahl aus der sich die Rangfolge ergibt Nach der Relative Weight Methode wird jeder Backlog Eintrag nach den vier Faktoren Vorteil, Strafe, Risiko und Kosten jeweils mit einer Zahl von 1 9 bewertet: 1. Vorteil: Wie groß ist der Vorteil (oder Wert) wenn das Feature geliefert wird? 2. Strafe: Wie groß fällt die Strafe aus, wenn das Feature nicht geliefert wird? 3. Risiko: Wie hoch ist das Risiko, sind Abhängigkeiten zu anderen Teams oder der Technik? 4. Kosten: Wie hoch sind die Kosten für die Umsetzung? 7

8 Während Vorteil und Strafe sehr schön aus Business-Sicht bewertet werden können, ist das Team prädestiniert, Hinweise zur Bewertung von Risiko und Kosten zu geben. Ist ein Feature zum Beispiel komplex in der Umsetzung mit vielen Abhängigkeiten zu anderen Umsystemem, wird das Risiko höher bewertet und sehr wahrscheinlich drückt sich das auch in einer höheren Aufwandsschätzung des Teams aus. Eine hohe Estimation bedeutet oft längere Umsetzungszeiten und höhere Kosten. Ein anderes Beispiel mit geringem Business Vorteil aber potentiell hoher Strafe wären der Impressumslink oder die Datenschutzerklärung auf Websites. Geld verdienen Sie mit dieser juristischen Anforderung nicht und auch für Ihre Kunden ist das womöglich wenig relevant, aber es kann schnell teuer werden, wenn sie wegen eines fehlenden Impressums abgemahnt werden. Die Prioritätszahl lässt sich mathematisch sehr leicht ermitteln: Bilden Sie die Summen aus Vorteil + Strafe und Risiko + Kosten und teilen diese durcheinander. Sie sehen am Beispiel oben, wie die Priorität steigt, wenn der Zähler im Bruch größer ist als der Nenner. Umgekehrt wird die Priorität geringer, wenn der Zähler kleiner als der Nenner wird. Das ist absolut sinnvoll. Ein Feature, das einen hohen Wert liefert und ohne Risiko und zu geringen Kosten umgesetzt werden kann ist höher einzustufen, als ein Feature von geringem Wert mit langer Entwicklungszeit und hohen Kosten. Kein Backlog Tweaking! Die feiner granulare Bewertung der Einzelkriterien zwingt Stakeholder, Product Owner und das Team dazu, sich über die wesentlichen Dinge zu einer Idee oder einer Funktion auszutauschen und diese objektiv zu bewerten. Das stellt sicher, dass alle Einträge methodisch und nicht etwa rein emotional bewertet werden. Kein Ist doch nen cooles Feature! Das sollte unbedingt zuerst gemacht werden. Zweimal 9 für Vorteil und Strafe! Ebenso hilft es, auch MUST have Features untereinander durch verschieden große Schätzungen und ihrer Risikobetrachtung in eine strikte Reihenfolge zu bringen. 8

9 Abbildung: Auszug aus einem Product Backlog das nach Relative Weight priorisiert wurde Brauchen Sie Hilfe? Ich hoffe, Sie haben einige Anregungen bekommen, die Sie in der Praxis nutzen können. Wenn Sie Fragen haben oder Feedback geben möchten, schreiben Sie mir an 9