In agilen Projekten werden Aufgabenpakete meist mit konfusen Zahlen geschätzt. Was steckt da eigentlich dahinter?
Der Mythos ist falsch, es muss nicht immer in Story Points geschätzt werden. Je nach Rahmenbedingungen kann gegebenenfalls sogar auf eine Schätzung verzichtet werden.
Story Points sind keine realen, sondern relative Werte, die von einem Team als Einschätzung der Schwierigkeit einer Aufgabe benutzt werden. Unter relativen Werten versteht man, dass die einzelnen Aufgaben im Verhältnis zueinander geschätzt werden.
Ein Team schätzt die Schwierigkeit einer Aufgabe über die Komplexität (Wie schwierig ist es?), das Risiko (Was muss alles beachtet werden?) und den Aufwand (Wie viel Zeit wird benötigt?). Unter Betrachtung dieser drei Merkmale bekommt eine User Story einen relativen Wert („Story Point“) zu den anderen, offenen User Stories. Story Points sind allerdings keine normalen Zahlen, sondern lehnen sich an die Fibonacci Zahlen an:
0.1..2…3…..5……..8………….13……………………20…………………………………….40……..……………………………………………….100
Diese sind so konzipiert, dass je höher sie werden, die Zahlen immer weiter auseinandergehen. Grund dafür ist, dass man die Schwierigkeiten von kleinen Aufgaben wesentlich leichter und genauer einschätzen kann als bei großen. Beispielsweise kann nicht genau gesagt werden, ob es 18 oder 21 wären, aber bei einer 2 oder 3 fällt einem das wesentlich leichter.
Bei SCRUM können verschiedene Schätzmethoden angewendet werden. Hierbei darf nicht verwechselt werden, dass Story Points eine mögliche Einheit darstellen. Das Estimation Game oder das Planning Poker sind zwei Methoden, um zu diesen Werten zu gelangen. Diese Schätzmethoden haben eine hohe Treffergenauigkeit, weil sich in ihnen die Erfahrung des Teams widerspiegelt. So kann eine Tätigkeit relativ genau (im Verhältnis zu den anderen Tätigkeiten) eingeschätzt werden.
Möchte man nun wissen, wann etwas umgesetzt wird, kann der Zeitpunkt/Zeitraum anhand der Velocity des Teams (Historie) hochgerechnet werden.
Hier ein Beispiel:
Team „Adlerauge“
Sprint 1: 16 Story Points
Sprint 2: 17 Story Points
Sprint 3: 19 Story Points
Sprint 4: 20 Story Points
Sprint 5: 18 Story Points
Velocity = (16+17+19+20+18) Story Points / 5 Sprints = 18 Story Points/Sprint
Demnach kann angenommen werden, dass das Team „Adlerauge“ pro Sprint ca. 18 Story Points schafft. Aber Achtung! Story Points sind subjektive Einschätzungen eines Teams und daher nicht auf andere Teams übertragbar. Dies bringt ein großes Risiko für falsche Interpretationen mit sich, da das Management oftmals versucht, Teams anhand ihrer erzielten Story Points miteinander zu vergleichen. Das ist aber so nicht möglich, da Story Points relative Schätzungen sind und andere Teams die Aufgaben möglicherweise anders beurteilen. Eine Möglichkeit wäre allerdings, die Arbeit der Teams über die umgesetzten Features zu beurteilen.
Es gibt sogar die Möglichkeit, ganz auf das Schätzen zu verzichten. Dies wird oft als „NoEstimates“ also „keine Schätzungen“ bezeichnet. Das Team konzentriert sich hierbei nicht darauf, wie groß eine Aufgabe genau ist, sondern ob diese soweit klar ist, dass sie bearbeitet werden kann. Dieses Konzept erspart dem Team zwar erheblich Zeit für das Schätzen, allerdings wird die Aufgabe nicht so tief erforscht, wobei mögliche Risiken und Probleme vielleicht unentdeckt bleiben.
Es muss also in SCRUM nicht immer mit Story Points geschätzt werden, allerdings ist es nicht ohne Grund der meist verbreitetste Weg.
Hintergrundinfos:
Estimation Game
Im Estimation Game wird die Rangfolge der User Stories diskutiert und mit Fibonacci Zahlen geschätzt. Im Magic Estimation wird die Rangfolge ohne Diskussion durch legen von Karten hergestellt und mit Fibonacci Zahlen geschätzt. Im Team Estimation Game erklärt jeder kurz seine Wahl. Es erfolgt wiederum keine Diskussion.
Planning Poker
Aufgrund historischer Daten schätzt das Team die Schwierigkeit einer Aufgabe ein. Jedes Teammitglied kann hierzu beispielsweise eine Karte mit dem geschätzten Wert umgedreht auf den Tisch legen, um die anderen in ihrer Einschätzung nicht zu beeinflussen. Alle Karten werden am Ende der Schätzung gleichzeitig aufgedeckt. Sind die Schätzungen zu weit auseinander, kann darüber diskutiert und die Schätzung wiederholt werden, bis grobe Einigkeit im Team herrscht.
