Relatives Schätzen: Von T-Shirt Größen zu Fibonacci-Werten

Im Projektmanagement wird an vielen Stellen geschätzt. Beim Plangetriebenen Projektmanagement wird absolut geschätzt, beispielsweise in Tagen (Dauer) oder auch in Personentagen (Aufwand). Beim Agilen Projektmanagement geht es darum, relativ zu schätzen. Es geht immer um den Bezug auf etwas.

Anforderungen werden hier oft als User Story formuliert, dabei wird oft bei der Schätzung des Aufwands mit T-Shirt Größen gearbeitet. Dazu wird eine Referenz benötigt. Nehmen wir einmal an, die User Story mit der ID=9 wird mit einer T-Shirt Größe “S”, geschätzt, dann werden alle anderen User Stories relativ dazu geschätzt.

Manche fragen an dieser Stelle, warum man nicht gleich Zahlen, z.B. die Fibonacci-Werte, verwendet. Dazu habe ich folgende Erläuterung gefunden:

“Wir verzichten darauf, die Fibonacci-Werte von Beginn an zu nutzen, weil wir möchten, dass das Team sich komplett vom Denken in Zahlen löst. Zahlen werden unbewusst immer wieder miteinander oder mit Tagen oder Stunden verglichen. Wir möchten erreichen, dass sich das Team auf »größer, gleich, kleiner« konzentriert und die Stories nur relativ zueinander schätzt” (Röpstorff/Wiedmann 2016).

Dennoch wird es irgendwann dazu kommen, dass man sich von den T-Shirt Größen löst und Zahlen nutzen möchte. Dazu werden für User Stories Zahlen aus der angepassten Fibonacci-Reihe genutzt, und als Story Points bezeichnet. Dabei kann folgende Gegenüberstellung nützlich sein:

T-Shirt GrößenStory Points
XS1
S2
M3
L5
XL8
XXL13
Quelle: Röpstorff/Wiedmann 2016

User Stories mit Story Points größer als 13 sollten noch einmal analysiert werden, denn es könnte sein, dass der Aufwand für einen Sprint zu groß ist, und es sich somit um ein Epic handelt.

Siehe dazu auch Planning Poker beim relativen Schätzen nutzen – analog oder auch online.

Agiles Projektmanagement: Was zeichnet ein gutes Product Backlog aus, und wie kann man es steuern?

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.