Das Product- und das Sprint-Backlog sind zwei Werkzeuge, die dem agilen Projektmanagement zur Koordination und Steuerung von Anforderungen und Aktivitäten innerhalb einer Timebox dient.
Product Backlog
Ist die Zielsetzung für das Projekt bzw. für das Produkt bekannt, werden, nachdem die User Stories verfasst wurden, diese in das Product Backlog eingestellt. Es macht natürlich keinen Sinn zu versuchen, vor der ersten Timebox bzw. Iteration das System bzw. das Produkt vollständig zu spezifizieren und hunderte oder sogar tausende User Stories zu verfassen. Außerdem würde ein solches Vorgehen dem vierten Grundsatz des agilen Manifests widersprechen und Freiräume für Veränderungen zerstören (siehe »Reagieren auf Veränderung mehr als das Befolgen eines Plans«) und Ressourcen verschwenden (MUDA; siehe »Lean und Kanban in der IT«)[1]. Das Product Backlog darf nicht als endgültige Spezifikation verstanden werden. Spezifiziert wird im agilen Projektmanagement primär über die direkte Kommunikation (siehe »User Stories«) mit dem Product Owner oder einem Netzwerk von Projektmitarbeitern (siehe »Netzwerke«) und das Product Backlog darf auch nie als vollständig angesehen werden.
Priorisierung des Product Backlogs
Das Product Backlog ist stets aktuell und priorisiert zu halten, damit die wichtigsten Anforderungen zielgerichtet detailliert, verfeinert und umgesetzt werden können. Das Priorisieren von Anforderungen ist in der Praxis nicht trivial. Es erfordert von dem Verantwortlichen tiefe Kenntnisse des Kunden und seiner Bedürfnisse (siehe »Akzeptanzkriterien, Conditions of Satisfaction«) Es gibt drei, in der Praxis häufig eingesetzte, Kriterien der Priorisierung[2]:
- Wert / Nutzen: Welcher Mehr- / Geschäftswert wird geschaffen?
- Chance / Risiko: Wird durch die Umsetzung ein Risiko beseitigt oder vermindert? Welche Chancen ergeben sich daraus?
- Kosten: Welche Kosten verursacht die Realisierung der Anforderung?
Aufgrund dieser Fragestellungen haben sich in diesem Projekt bei der Priorisierung folgende Methoden etabliert:
- ABC-XYZ-Analyse
- Kano-Modell
- MuSCoW-Priorisierung
ABC-XYZ-Analse
Die ABC-XYZ-Analyse[3] kann ebenfalls als Instrument zur Prioritätensetzung verwendet werden, wenn man die Schwankungen aus der XYZ-Analyse mit der Kundenzufriedenheit ersetzt. Die Kundenzufriedenheit wird hier als die Zufriedenheit der Fachabteilungen und deren Erwartungshaltung an die gestellten Anforderungen verstanden. Da sich aufgrund des Geschäftsumfeldes Erwartungshaltungen ändern können (Moving Targets zum Beispiel aufgrund der Wirtschaftskrise) kommt dieser Art der Klassifizierung von Anforderungen ein großes Gewicht zu und wurden auch im Projekt monatlich neu bewertet.
| AZ Hoher Wert / Nutzen Geringe Kundenzufriedenheit | BZ Mittlerer Wert / Nutzen Geringe Kundenzufriedenheit | CZ Niedriger Wert / Nutzen Geringe Kundenzufriedenheit |
| AY Hoher Wert / Nutzen Mittlere Kundenzufriedenheit | BY Mittlerer Wert / Nutzen Mittlere Kundenzufriedenheit | CY Niedriger Wert / Nutzen Mittlere Kundenzufriedenheit |
| AX Hoher Wert / Nutzen Hohe Kundenzufriedenheit | BX Mittlerer Wert / Nutzen Hohe Kundenzufriedenheit | CX Niedriger Wert Hohe Kundenzufriedenheit |
Kano-Modell
Das Kano-Modell[4] ist ebenfalls ein Instrument zur Prioritätensetzung und beinhaltet in seinem Modell bereits die Kundenzufriedenheit. Das Kano-Modell stellt die Kundenzufriedenheit über den Erfüllungsgrad der Kundenwünsche und – anforderungen dar.
Basisanforderungen sind essenzielle Bausteine. Meist wird aus diesem Grund ein Projekt initialisiert bzw. aus Produktsicht sind dies die wertvollsten Anforderungen. Das Kano-Modell sagt aber interessanterweise voraus, dass Basisanforderungen bzw. Basisqualität sehr rasch zu einer Stagnation der Kundenzufriedenheit führen. Leistungsmerkmale bzw. Leistungsqualität führen zu einem linearen Anstieg der Kundenzufriedenheit.
In agilen Festpreisprojekten muss hier besonders Acht gegeben werden, denn diese Kurve besagt »Je mehr, desto besser«! Begeisterungsmerkmale bzw. Begeisterungsqualität bedingt eine sehr hohe Kundenzufriedenheit. In Projekten, speziell in agilen Festpreisprojekten ist eine geschickte Kombination von allen drei Bereichen sehr hilfreich, um die Kundenzufriedenheit und den Mehrwert bzw. Nutzen gegeneinander zu optimieren[5].
Die Ergebnisse aus der ABC-XYZ-Analyse und dem Kano-Modell lassen sich vereinfacht in die MuSCoW-Priorisierung überführen und in dem Product Backlog festlegen.
Die MuSCoW-Priorisierung differenziert dann die Anforderungen in vier Bereiche:
- Must have
- Should have
- Could have
- Won’t have
Sprint-Backlog
Das Sprint-Backlog enthält alle Aktivitäten die für die Umsetzung der zuvor priorisierten und ausgewählten User Stories bzw. Anforderungen notwendig sind. Diese Aktivitäten werden in einem separaten Meeting[7] in Aufwandsstunden geschätzt und das Team verpflichtet sich (siehe »Commitment und Identifikation«) durch ihr eigenes Zeitmanagement, diese Anforderungen in der geplanten Timebox umzusetzen. Die Aktivitäten werden so genau wie möglich beschrieben.
Das Sprint-Backlog ist ein sich täglich änderndes Artefakt und ist ein sehr transparentes Mittel für die Darstellung der Projektorganisation und des Projektfortschrittes. Zur visuellen Darstellung werden standardmäßig das Task- und Kanbanboard (siehe unten »Task- und Kanbanboard«).
Task- und Kanbanboard
Agiles Projektmanagement hat sehr viel mit Transparenz und kontinuierlicher Verbesserung zu tun. Das Sprint-Backlog kann entweder auf elektronische Art und Weise dargestellt werden, oder man verwendet Karteikarten und Post-It´s, die an einer Wand oder Stellwand befestigt werden[8]. Die visuelle Struktur eines Task- oder Kanbanboards orientiert sich nach den Phasen der Wertschöpfungskette oder nach bestimmen Status (z.B. in Arbeit, erledigt, etc.). Fortgeschrittene Task- und Kanbanboards visualisieren darüber hinaus auch die limitierten Mengen für jede Phase. Die oben genannten Methoden sind zentrale Techniken von Kanban und charakterisieren auch typische Elemente wie das Pull-Verfahren, limitierte Mengen (siehe »Entwicklungsgeschwindigkeit, Velocity«) und die transparenten Informationen, die sich jeden Tag ändern können. Im agilen Projektmanagement haben sich hierzu das Verwenden einer Stellwand oder Zimmerwände (siehe »Einführung des Taskboards und des Daily Meetings«) durchgesetzt, sodass alle Teammitglieder jederzeit direkten Zugang zu den Task- und Kanbanboards haben und Änderungen am Plan diskutieren und aktualisieren können. Die Abbildung »Task- und Kanbanboard« zeigt eine mögliche Struktur eines Task- und Kanbanboards. Die oberen Kreise in der Abbildung zeigen die Limitationen der max. zulässigen Elemente einer Phase. Der linke Teil enthält die Anforderungen und die einzelnen Aktivitäten zu der zugeordneten Anforderung einer Zeile[9].
Die User Story entspricht hier in ähnlicher Weise der Signalkarte in Kanban und enthält die wichtigsten Informationen über die Anforderungen, deren Aufgaben und Aktivitäten in einzelne Task aufgeteilt werden. Die einzelnen Tasks einer Story Card werden eigenständig von einem Entwickler im Pull-Verfahren von der Story Card übernommen, personalisiert und noch einmal geschätzt (siehe Abbildung »Task eines Kanbanboards«).
[1] Pichler; Roman: Scrum, Agiles Projektmanagement erfolgreich einsetzen; 1. Auflage; dpunkt.verlag GmbH; Heidelberg; 2008; S. 34ff.
[2] Pichler; Roman: Scrum, Agiles Projektmanagement erfolgreich einsetzen; 1. Auflage; dpunkt.verlag GmbH; Heidelberg; 2008; S. 38ff.
[3] Hering, Ekbert, Frick, Gerold: Betriebswirtschaft in Fallbeispielen; 1. Auflage; Carl Hanser Verlag; München Wien; 2003; S.139ff
[4] von Regius, Bernd: Qualität in der Produktentwicklung, Vom Kundenwunsch bis zum fehlerfreien Produkt; 1. Auflage; Carl Hanser Verlag; München Wien; 2006; S.23ff.
[5] Pichler; Roman: Scrum, Agiles Projektmanagement erfolgreich einsetzen; 1. Auflage; dpunkt.verlag GmbH; Heidelberg; 2008; S. 39f.
[6] von Regius, Bernd: Qualität in der Produktentwicklung, Vom Kundenwunsch bis zum fehlerfreien Produkt; 1. Auflage; Carl Hanser Verlag; München Wien; 2006; S.24.
[7] In Scrum heißt das Meeting »Sprint-Planungsmeeting«.
[8] Pichler; Roman: Scrum, Agiles Projektmanagement erfolgreich einsetzen; 1. Auflage; dpunkt.verlag GmbH; Heidelberg; 2008; S. 102ff.
[9] Epping, Thomas: Kanban für die Softwareentwicklung, 1. Auflage; Springer-Verlag, Berlin Heidelberg; 2011; S.115ff.
No Comments