Das Product Backlog ist ein wichtiger Bestandteil agiler Software-Entwicklungsprojekte: Es enthält alle Arbeiten, die für die Erstellung einer erfolgreichen Anwendung erforderlich sind. Nicht selten umfasst ein solches Backlog weit über 50 unterschiedliche User Stories (in großen Projekten können es auch mehrere Hundert sein), von denen es nur ein Teil in die nächste Produktversion schaffen kann. Für den Product Owner ist es keine einfache Aufgabe zu entscheiden, in welcher Reihenfolge die Stories umgesetzt werden sollen.
Glücklicherweise gibt es ein paar Ansätze, die bei der Entscheidung helfen können. Vier Möglichkeiten zur Priorisierung des Backlogs stellen wir Ihnen hier vor: Kano-Analyse, Theme Screening, Theme Scoring und relative Gewichtung.
Die Bedeutung guter Backlog-Priorisierung
Die gute Pflege und Führung des Product Backlogs ist ein wichtiger Erfolgsfaktor für die Produktentwicklung. Ein gut geführtes Backlog stellt sicher, dass nur Funktionalitäten realisiert werden, die den Anwendern wirklich einen Nutzen bringen. Die agile Software-Entwicklung verfolgt in der Regel das Ziel, das Produkt bereits frühzeitig auszuliefern, um Feedback zur Marktakzeptanz zu generieren: Je früher also die grundlegenden Features realisiert sind, desto eher ist das Produkt auslieferbar und einsatzbereit.
Priorisierungsentscheidungen sollten immer eine solide Grundlage haben, etwa Umfrageergebnisse, Statistiken und ähnliche Daten. Dabei geht es nicht um einen streng wissenschaftlichen Ansatz mit größter Genauigkeit: Das Feedback von 20 bis 30 Nutzern kann schon viel aussagen – sofern es systematisch und auswertbar eingeholt wird.
Kano-Analyse
Bei der Kano-Analyse wird eine Befragung von Anwendern durchgeführt, durch die eine Klassifizierung der Funktionalitäten in verschiedene Kategorien möglich ist:
- Basisfaktoren: Basisfaktoren setzen die Anwender als selbstverständlich voraus, sie sind unbedingt erforderlich. Sind diese Funktionen enthalten, entsteht keine Zufriedenheit, fehlen sie, entsteht allerdings Unzufriedenheit.
- Leistungsfaktoren: Diese Faktoren wirken linear. Ein Mehr im Hinblick auf eine solcher Funktionalität führt zu mehr Zufriedenheit beim Anwender oder zur Beseitigung von Unzufriedenheit.
- Begeisterungsfaktoren: Begeisterungsfaktoren sind Funktionen, die der Anwender so nicht erwartet, sie überraschen ihn positiv. Als Beispiel nennt Mike Cohn einen Dosenhalter im Auto, der 1993 noch keineswegs selbstverständlich war und den seine Frau toll fand. Ein Begeisterungsfaktor kann sogar das “Zünglein an der Waage” für eine Kaufentscheidung sein.
Abb.: Das Kano-Modell in seiner Grundfassung
Manchmal ist es gerechtfertigt und sinnvoll zu schätzen, in welche Kategorie eine Funktionalität fällt. Zu wirklich belastbaren Ergebnissen führt aber eher eine Befragung einer kleinen Nutzergruppe: Wie angesprochen, reichen 20 bis 30 Teilnehmer oft schon aus. Die Befragung kann auch in Form einer Online-Umfrage durchgeführt werden.
Ein Tipp für die Release-Planung: Basisfaktoren sind Pflicht und sollten sämtlich integriert werden, da sonst mit Unzufriedenheit zu rechnen ist. Darüber hinaus sollte man einige lineare Funktionalitäten und wenigstens ein paar Begeisterungsfaktoren einplanen.
Theme Screening
Das Vorgehen beim Theme Screening folgt diesen Schritten:
- Identifizieren Sie zunächst die Faktoren, die für die Priorisierung des nächsten Releases als Kriterien herangezogen werden sollen, beispielsweise die Bedeutung für die bestehenden Anwender, die Gewinnung neuer Anwender oder die Generierung von Umsatz. Diese Kriterien werden als Reihen in eine Tabelle eingetragen. Es sollten etwa fünf bis neun solcher Kriterien sein.
- Nach der Festlegung der Priorisierungskriterien wird ein sog. Baseline Theme gewählt, eine Story oder ein Theme, die bzw. das im weiteren Vergleich als Basis für die relative Bewertung dient. Dafür eignen sich Stories oder Themes, die wahrscheinlich in das nächste Release aufgenommen werden und die den Teammitgliedern vertraut und für alle verständlich sind. Es sollte sich allerdings nicht um das wichtigste Theme handeln, da dann alle weiteren Themes im Verhältnis schlechter abschneiden würden. Die Festlegung des Baseline Themes erfolgt also analog zur relativen Beschätzung eines Product Backlogs, bei der zumeist eine mittelgroße oder eher kleine Story als Ausgangsgröße herangezogen wird.
- 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 Minus eingetragen, für die besser abschneidenden ein Plus und für die gleich zu bewertenden Themes eine Null.
Die Plus-Wertungen werden dann aufsummiert und die Minus-Wertungen abgezogen. Ist das für alle Themes erledigt, können sie entsprechend ihrer Punktzahl aufgereiht werden und die Priorisierung steht.
Theme Scoring
Theme Scoring ist dem Theme Screening sehr ähnlich. Auch hier geht es darum, verschiedene Themes gegeneinander abzuwägen. Im ersten Schritt werden die verschiedenen Kriterien zusammengestellt, nach denen die Bewertung erfolgen soll. Dann ist eine Bewertung der Kriterien erforderlich. Dafür erhalten sie Prozentwerte, die sich zu 100 Prozent aufsummieren.
Anschließend werden wieder alle Themes nebeneinander gestellt. Dann wird die Erfüllung der Kriterien für alle Themes auf einer Fünfer-Skala bewertet, wobei 1 für eine schlechte Erfüllung und 5 für eine gute Erfüllung des Kriteriums steht. Dabei ist es hilfreich, im Vorfeld für alle Kriterien ein Basis-Theme festzulegen, das eine Bewertung von drei Punkten erhält. Somit lassen sich die anderen Themes leichter im Verhältnis zum jeweiligen Basis-Theme bewerten.
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.
Dabei trägt das Team die Themes in die Reihen einer Tabelle ein und gibt dann jeweils eine Bewertung für den Nutzen der Funktion bei Bestehen und die Höhe der "Strafe" bei Abwesenheit ab. Zusätzlich wird noch ein Wert für den geschätzten Aufwand eingetragen, beispielsweise in Form von Story Points oder auch Euro-Beträgen. Diese Methode berücksichtigt also auch die Kosten einer Funktionalität explizit.
Schließlich schaut das Team, welchen Anteil am Gesamtnutzen und welchen Anteil an den Gesamtkosten eine bestimmte Funktionalität hat. Diese beiden Werte werden dividiert und ergeben eine Priorisierungskennzahl:
| Anteil am Gesamtnutzen | Anteil an den Gesamtkosten | Priorisierung |
| 57 % | 67 % | 0.85 |
| 43 % | 33 % | 1.30 |
In diesem Beispiel bringt das untere Feature zwar einen geringeren Nutzen, ist aber ein ganzes Stück günstiger und hat dadurch einen höheren Return on Investment (ROI).
Fazit: Methoden können helfen, Auswahl hängt von der Situation ab
Diese vier Methoden können dabei helfen, systematisch an die Priorisierung eines Product Backlogs heranzugehen. Allerdings kann es keine Grundsatzempfehlungen geben, wann welche Methode die beste Lösung ist: Die Wahl des Vorgehens hängt von der jeweiligen Situation ab.
Es empfiehlt sich, mit diesen Ansätzen zu experimentieren und Erfahrung mit den verschiedenen Varianten zu sammeln. Durch die Einbeziehung von Anwendern lässt sich zudem für einen größeren "Market-fit" sorgen.
"Agile" einführen oder optimieren? Wir sind Ihr Partner!
Haben Sie Fragen zu agilen Vorgehensweisen in der Software-Entwicklung? Möchten Sie Agilität in Ihrem Unternehmen einführen oder bestehende Prozesse verbessern? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Gerne helfen wir Ihnen bei der Etablierung und Optimierung agiler Prinzipien und Verfahren in Ihrem Unternehmen – sprechen Sie uns einfach unverbindlich an. Ausführliche Informationen zu unseren Agile-Dienstleistungen finden Sie in unserem Agile-Orientierungsangebot mit Leistungsbeschreibungen und Beispielkalkulationen.
Weiterführende Infos
Vorgehen nach Scrum: Die beste Wahl für den Kunden, die Agentur - und das Produkt
Agile vs. Wasserfall-Modell: Was die Forschung sagt
Scrum: Welche Eigenschaften sollte ein gutes Product Backlog haben?
Agile Projekte und Scrum in der Praxis: Elemente, Nutzen, Tools, Hürden
Scrum in der Praxis: Ein Team startet durch
Mehr über die Creative-Commons-Lizenz erfahren
