Schätzen von Anforderungen und Aufgaben

Eine Anforderung muss so formuliert werden, dass das Team in der Lage ist, ihren Aufwand zu schätzen. Der Product Owner formuliert seine fachlichen Anforderungen in Form von Items, das Team spezifiziert diese, in dem es dem Item Tätigkeiten, sogenannte »Tasks«, zuordnet. Die Aufwände können entweder auf der Ebene der Items oder auf Ebene der Tasks vom Team geschätzt werden.

Planungsaufgaben für Product Owner und Team


Es gibt verschiedene Arten, dokumentierte Anforderungen zu schätzen. In Scrum werden häufig zwei Varianten verwendet:

Planning Poker

Die erste Variante ist das sogenannte »Planning Poker«. Hier werden Aufwandskategorien definiert, die dann den Items oder Tasks zugeordnet werden. Die Aufwandskategorien werden zunächst fachlich beschrieben, zum Beispiel »sehr geringer Aufwand«, »geringer Aufwand«, »neutraler Aufwand«, »höherer Aufwand«, »sehr hoher Aufwand«, »extrem hoher Aufwand«. Diesen Kategorien teilt man dann die Zahlen zum Beispiel der Fibonacci-Reihe zu, da hier die Abstände zwischen den Zahlen immer größer werden.

Folgende Aufteilung der Aufwands-Kategorien ergibt sich:

Scrum Aufwands-Kategorien: 1 entspricht »sehr geringer Aufwand«, 2 entspricht »geringer Aufwand«, 3 entspricht »sehr neutraler Aufwand«, 5 entspricht »höherer Aufwand«, 8 entspricht »sehr hoher Aufwand« und 13 entspricht »extrem hoher Aufwand«.

Tabelle 4 – Aufwands-Kategorien


Das Team trifft sich zum Planning Poker und bewertet die einzelnen Items mit einer Zahl der Fibonacci-Reihe. Das erste Teammitglied bewertet beispielsweise einen Item mit drei; das zweite Teammitglied mit zwei und das dritte Teammitglied mit acht. Somit variiert die Bewertung um einige Punkte. Dieses Beispiel zeigt, dass das Team offenbar Schwierigkeiten hat, sich einer gemeinsamen Aufwandskategorie anzunähern – hier besteht Klärungsbedarf. Das Team wird nun dieses Item oder denTask weiter im Detail beschreiben, so dass die Schätzung besser möglich ist.

Das Team nimmt dann pro Sprint eine gewisse Anzahl von Items auf. Durch die Zuordnung der Aufwände nach Kategorien findet das Team von Sprint zu Sprint heraus, wie viele Items nach den oben genannten Kategorien pro Sprint realisiert werden können.

Bestell unser Planning Poker Kartenspiel mit unserem Scrum Kit oder lade die kostenfreie Smartphone-App.

Reale Tage und die Beta-Verteilung

Die zweite Variante ist das Schätzen und Planen von realen Tagen. Es wird zunächst festgehalten, wie viele Stunden real zur Entwicklung pro Tag zur Verfügung stehen. Beispielsweise fünf von acht Arbeitsstunden pro Tag. Diese werden dann vom Team verplant. Jedes Item wird um seine Aufageben erweitert und von den Teammitgliedern geschätzt. Hier können unterschiedliche Schätzverfahren eingesetzt werden, bspw. PERT (Program Evaluation and Review Technique) aus dem klassischen Projektmanagement.

Folgende drei Werte sind relevant: Aufwand im besten Fall (engl.: Best Case), Aufwand im Durchschnitt (engl.: Average Case) und Aufwand im schlechtesten Fall (engl.: Worst Case). Durch diese Drei-Punkt-Schätzung enthält die Aufgabe automatisch die subjektiven Einschätzungen des Schätzers. Aufgaben können auch von mehreren Personen gleichzeitig oder auch nacheinander geschätzt werden. Die Berechnung ergibt die mittlere Dauer.

Beispiel-Berechnung:

Task 1 hat im Best Case vier Stunden, im Average Case sechs Stunden und im Worst Case 18 Stunden. Diese Schätzung gibt direkte Auskunft darüber, dass sich hier einige Unsicherheiten verbergen, denn der Worst Case ist dreimal so hoch wie der angenommene Normalfall.

Aus der Betaverteilung ergibt sich folgende Formel:

Scrum Pert Formel: dmittel = (dmin + 4 * dnorm + dmax) / 6

Abbildung 23 – Formel


Sie ergibt in diesem Fall 7,66 Stunden. Weitere zusätzliche Verfahren, wie z. B. die Berechnung der Standard-Abweichung, können zusätzliche Hinweise auf die Unsicherheit der Schätzung geben.

In diesem Verfahren würde dann vom Team entweder eine Spezifizierung des Tasks stattfinden, da zu viel Unsicherheit in der Schätzung ist, oder es würden die 7,66 Stunden verplant. Da ein realer Tag nur fünf Stunden hat, würden hier somit ca. 1,5 Tage Entwicklung eingeplant werden.

Puffer können in der Planung dadurch berechnet werden, indem weitere Sigma (Standardabweichung) der Dreipunktschätzungen berücksichtigt werden und auf den Schätzaufwand addiert werden. Damit wird mit einer statistischen Wahrscheinlichkeit ausgesagt, dass der geplante Aufwand eintritt. Drei Sigmas entsprechen einer statistischen Genauigkeit von 99,7 %.


Organisation des Product Backlogs

Über itemis

Die itemis AG ist ein unabhängiges IT-Beratungs­unternehmen, das leistungsfähige Software für Unternehmens­anwendungen, eingebettete Systeme und mobile Applikationen entwickelt – und über diese Themen bloggt.