Das Backlog priorisieren
7. März 2011
Einer der wichtigsten Bestandteile eines agilen Projektes ist ein gut gepflegtes Backlog. Und ein gut gepflegtes Backlog ist natürlich auch priorisiert. Doch wie macht man das eigentlich? Welche Parameter sind bei der Priorisierung zu berücksichtigen? Wie so oft, gibt es hierzu keine endgültige, beste Antwort, sondern nur Hinweise, was berücksichtigt werden sollte:
- Wie hoch ist der Nutzen des Backlog Items?
In einer idealen Welt lässt sich der Nutzen direkt in einem monetären Wert ausdrücken, in der Praxis ist dies eher selten der Fall. Dies entbindet den ProductOwner aber nicht von der Aufgabe, eine Nutzenschätzung für die Items durchzuführen. Und seien es auch nur Business Value Points, die nach Bauchgefühl vergeben werden. Auch diese erlauben eine Bewertung der Features zu einander. - Wie komplex ist die User Story?
Es gibt gute Gründe, schwierige Dinge sofort anzugehen und nicht auf die lange Bank zu schieben. Natürlich ist nicht jede schwierige Aufgabe sofort zu erledigen, es muss auch der Nutzen betrachtet werden. Features, die wenig Nutzen bringen, aber eine hohe Komplexität bergen, sollte man nach unten priorisieren. Items mit hoher Komplexität und hohem Nutzen aber schnellstmöglich angehen. - Wie dringend ist eine User Story?
Es gibt Aufgaben, die bestechen nicht durch den damit verbundenen Nutzwert, müssen aber – meist aufgrund externer Vorgaben – dennoch zu einem bestimmten Zeitpunkt erledigt werden. Diese Stories sind so auf dem Backlog einzuplanen, dass die Fertigstellung rechtzeitig vor der Fälligkeit gewährleistet ist. Und der letzte möglich Sprint ist dabei nicht immer die beste Wahl, denn es soll schon vorgekommen sein, dass ein Commitment nicht gehalten werden konnte. - Steht die Story im Einklang mit der Strategie?
Es gibt immer wieder Produktideen, die sind bestechend, widersprechen aber fundamental der Unternehmensstrategie bzw. der Produktstrategie, z.B. weil sie nicht die geplante Zielgruppe ansprechen. Es steht außer Frage, dass man vielversprechende Ideen weiter verfolgen sollte, aber nicht in einem Projekt, dass Ziele verfolgt, die der Idee entgegen stehen. Backlog Items, die nicht mit der Strategie in Einklang zu bringen sind, sollten daher aussortiert werden. - MusCoW
Auch anhand der MusCoW-Kriterien lassen sich Items klassifizieren: Handelt es sich um „Must have“, „Should have“ oder „Could have“? Items, die mit „Won‘t have“ klassifiziert würden, kann man getrost sofort von seinem Backlog streichen, die anderen sollten entsprechend der Klassifizierung einsortiert werden. - Nutzerfeedback
Wie wichtig ist den Benutzern die geplante Funktionalität? Häufig ergeben sich aus Benutzerbefragungen eindeutige Präferenzen für bestimmten Funktionen. Diese können ebenfalls bei der Priorisierung des Backlog berücksichtigt werden.
Neben den hier beschriebenen sind noch viele weitere Parameter für die Bewertung denkbar. Und natürlich wird es immer wieder zu Diskussionen über die richtige Reihenfolge kommen. Hier kann jedoch Scrum eine seiner Stärken ausspielen: Es gibt eine klar definierte Person, die für das Backlog und damit für die Priorisierung zuständig ist: Der Product Owner. Er hat sammelt den Input ein und legt die Priorisierung fest. Er hat das letzte Wort und trägt damit aber auch die Verantwortung für den Projekterfolg.
Quelle Bild: © raywoo – Fotolia.com
| Keine Kommentare