Es ist auch im Agilen Projektmanagement gut, mit Metriken zu arbeiten, und diese zur Steuerung zu verwenden. Einzelne Steuerungstechniken wie Burn-Down Charts, Burn-Up Charts, Velocity oder Cumulative Flow Diagram werden oft relativ isoliert betrachtet und möglicherweise irgendwann einmal in ein OKR (Objectives and Key Results) überführt. Dieser Weg ist für viele Organisationen allerdings noch sehr lang. Es stellt sich daher die Frage, was man mit den oftmals vorhandenen Steuerungstechniken verbessert machen kann. In dem folgenden Beispiel betrachten wir im Scrum Rahmenwerk (Framework) das Product Backlog etwas genauer.
Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden (Schwaber/Sutherland 2020). Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird. Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Der Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich (Gareis/Gareis 2017:137). Es gibt einige Qualitätskriterien (wie z.B. DEEP) die beschreiben, was ein gutes Product Backlog ausmacht, doch geht es noch besser, noch quantitativer? Antwort: Ja, durchaus.
“Ein gutes Backlog zeichnet sich vor allem dadurch aus, dass die darin enthaltenen User Stories gut beschrieben sind. Sie benötigen Story Points für die Komplexitätsmessung, einen Prioritätswert, einen Business Value und eine Risikobewertung. Um die Qualität des Backlogs zu messen, kann beispielsweise eine kombinierte Metrik mit folgenden Kenngrößen verwendet werden:
• Anzahl der User Stories im Backlog verglichen mit einem festgelegten Zielwert.
• Verweildauer der User Stories im Backlog bzw. Dauer zwischen Erstellung und Übergang in den Status ´Ready´.
• Gruppierung der User Stories nach Priorität, Anzahl Story Points, Business Value bzw. Risikobewertung und Vergleich mit festgelegten Zielwerten.
(…) In diesem Beispiel sind 30 User Stories im Product Backlog (Zielwert 50). Diese haben eine Komplexität von 1.600 Story Points (Zielwert 2.000) und einen Business Value von 1.050 (Zielwert 1.500). Je Kategorie wird zusätzlich die Verteilung auf Prioritäten von eins bis vier gezeigt. Aufgrund der Abweichungen gegenüber den Zielwerten ergibt sich ein gemittelter Gesamterfüllungsgrad von 70%” (Brüggenkamp et al. 2020: Metriken in agilen Projekten. In: projektmanagementaktuell 4/2020, S. 53-59).
Interessant ist, dass die Autoren auch eine Visualisierung der quantitativen Werte in einer Backlog Health Chart vorschlagen, aus der dann sogar Trendanalysen ableitbar sind. Hier wäre ich allerdings etwas vorsichtiger, da es in einem agilen Vorgehensmodell immer wieder zu stärkeren Veränderungen kommt, die so nicht immer vorhersehbar sind. Dennoch halte ich den in dem Artikel aufgezeigten Ansatz für praktikabel und nützlich.
In den von uns entwickelten Blended Learning Lehrgängen Projektmanager/in (IHK) und Projektmanager/in AGIL (IHK) gehen wir auf solche Zusammenhänge ein. Informationen zu den Lehrgängen und zu aktuellen Terminen finden Sie auf unserer Lernplattform.
