Das Schätzen von Anforderungen ist ein Kernthema agiler Entwicklung. Auf ihr basiert die gesamte Ablaufplanung. Anders als in herkömmlichen Techniken ist dabei das Schätzen ein fortlaufender Prozess, der parallel zum Entwicklungsprozess durchgeführt wird und bei dem einmal geschätzte Anforderungen auch mehrfach geschätzt werden, da sich basierend auf Kundenfeedback, aber auch auf den selbst gewonnenen Erkenntnissen während des Entwicklungsprozesses neue Gesichtspunkte ergeben können, die die Aufwandsschätzungen beeinflussen können.
Im Rahmen des Backlog Refinements – auch Backlog Grooming genannt – kommt das Team zusammen, um Anforderungen, welche oft als User-Stories vorliegen, zu schätzen. Anders als die «Events» in Scrum findet Backlog Refinement nicht einmalig zu einem bestimmten Zeitpunkt im Sprint statt. Auch existiert keine Timebox. Das Team vereinbart gemeinsam, wann sich alle treffen, um gemeinsam an den Anforderungen zu arbeiten. Dafür sollte nicht mehr als 10% der Arbeitszeit des Entwicklerteams eingesetzt werden. Das macht auf eine Arbeitswoche immerhin durchschnittlich einen halben Tag aus. In der Praxis hat sich gezeigt, dass es sinnvoll ist, wenn das Refinement nicht zu Beginn oder Ende eines Sprints angesetzt wird, da das Team in diesen Zeiträumen mit anderen Aufgaben absorbiert ist.
Das Backlog Grooming wird so angesetzt, dass es für das ganze Team passt. Der Scrum Master organisiert das Meeting und setzt den Rahmen. Nun werden eine oder mehrere Anforderungen nacheinander geschätzt. Dabei stellt der Product Owner das gewünschte Feature vor und beantwortet die Fragen des Teams dazu. Fragen können sich dabei um Inhalt, Umfang, Anforderungen, Akzeptanzkriterien etc. drehen. Wenn alle Teammitglieder überzeugt sind, dass sie die Aufgabenstellung richtig verstanden haben, wird die Schätzung angegangen. Scrum-Poker ist dabei die gebräuchlichste Methode.
Story-Points
Geschätzt wird in Story-Points, einem virtuellen Mass, das auf dem Vergleich des Aufwandes einer Anforderung mit einer Referenzstory basiert. Dazu wird vom Team eine Aufgabenstellung, deren Umsetzung für alle nachvollziehbar ist, verglichen. Der Aufwand der Referenzstory wird dabei als 1 Story-Point gesetzt. Wenn nun andere Anforderungen geschätzt werden sollen, so wird lediglich verglichen, wie deren Aufwand in Relation zur Referenzstory ist.
Ein Beispiel aus dem Alltag mag die Vorgehensweise weiter erläutern. Nehmen wir an, Ihr Team wäre Ihre Familie. Als Referenzstory wählen Sie das Decken des Tisches für die ganze Familie mit jeweils Gabel und Messer, einem Teller, einem Salatteller, Trinkglas und Serviette. Alle in der Familie können sich vorstellen, wie gross der Aufwand dafür ist. Soll nun eine andere Anforderung, beispielsweise das Zubereiten eines gemischten Salats mit drei verschiedenen Sorten Salat, erfüllt werden, so würde die Familie womöglich genauer zurückfragen, welche Salatsorten denn vorgesehen seien und ob die Salatsauce selbst hergestellt oder eine gekaufte verwendet werde. Anschließend haben alle eine Vorstellung vom Umfang der Aufgabe und es werden womöglich Schätzungen, zwischen 2 und 5 Story-Points, genannt werden.
Es gibt mehrere Gründe, warum sich der Einsatz einer virtuellen Größe wie Story-Points gegenüber festen Werten wie «X Personentagen» anbietet. Zum einen soll mit dieser virtuellen Größe das Bewusstsein unterstützt werden, dass es sich um Schätzgrößen handelt und nicht um verbindliche Aufwandsangaben, auf welche das Entwicklungsteam behaftet werden wird («No Blame Ansatz»). Andererseits verändert sich die Geschwindigkeit des Entwicklungsteams und eine Aussage, dass die Umsetzung einer User-Story einen Aufwand von «5 Entwicklertagen» bedeute, müsste dann sinnvollerweise mit einer Referenzierung zu einem bestimmten Sprint gegeben werden.
Scrum-Poker
Im Kontext eines Entwicklungsteams ist das Vorgehen ganz ähnlich. Auch hier wird gemeinsam eine Referenzstory bestimmt und darauf basierend gibt jedes Teammitglied seine Schätzung ab. Es hat sich aber gezeigt, dass es zu einer Beeinflussung kommen würde, wenn die Teammitglieder von Anfang an ihre Schätzungen kommunizieren würden. Da würde womöglich der erfahrene Vorredner eine relativ hohe Schätzung abgeben, welche weit über der eigenen liegen würde. Das würde zu einer Beeinflussung führen und die nachfolgenden Schätzer würden ihre Schätzungen tendenziell basierend auf seiner Schätzung anpassen. Niemand möchte den Eindruck erwecken wollen, dass er nicht alle Aspekte berücksichtigt hat, welche einem anderen aufgefallen sind. Andererseits würde eine sehr tiefe Schätzung eines Vorredners dazu führen, dass man ggf. weit höhere Schätzungen anpassen würde, um nicht als «die Schnecke» angesehen zu werden.
Um gegenseitige Beeinflussungen auszuschliessen, hat sich Scrum-Poker bewährt. Dabei schätzt jedes Teammitglied zunächst für sich und legt eine Karte mit dem entsprechenden Zahlenwert in Story-Points verdeckt vor sich hin. Wenn alle geschätzt haben, werden die Schätzungen aufgedeckt und die unterschiedlichen Herangehensweisen werden besprochen. «Du hast 5 Story-Points geschätzt – wie würdest Du vorgehen?» oder «Ich habe 20 Story-Points geschätzt, weil ich den Eindruck habe, dass das Interface, welches wir einsetzen werden, neu geschrieben werden muss. Das, was wir bisher eingesetzt haben …». So sprechen sich die Entwickler ab und gewinnen dabei verschiedene Ideen über Lösungsansätze. Womöglich stellen sie dabei auch fest, dass sie Anforderungen unterschiedlich verstanden haben und nochmals den Product Owner befragen müssen. Sind dann alle Fragen geklärt, kommt es zu einem zweiten Durchgang der Schätzung. Wie mit dann noch vorliegenden Unterschieden umgegangen werden soll, definiert das Team für sich selbst: Soll die Maximalschätzung genommen werden, der Durchschnitt oder soll nochmals diskutiert werden? Was immer die finale Schätzung ist – sie muss von allen Teammitgliedern mitgetragen werden können. Nur dann werden sie sich im Sprint auch committen können.
Beim Einsatz von Scrum-Poker-Karten fällt auf, dass dabei eine besondere Zahlenfolge vorliegt. Es handelt sich dabei meist um eine geglättete Fibonacci-Zahlenfolge. Die Sequenz geht auf den wohl bedeutendsten Mathematiker des Mittelalters, Leonardo da Pisa, der auch Fibonacci genannt wurde, zurück, der von 1170 bis ca. 1240 in Pisa lebte. Die nach ihm benannte Zahlenfolge lautet «1, 1, 2, 3, 5, 8, 13, 21, 34, 55 …». Er hat diese nicht selbst entdeckt, vielmehr war sie schon den antiken Griechen und Indern bekannt. Gebildet wird eine Folgezahl jeweils durch die Addition der beiden davorliegenden Zahlen (z.B. 21 +34=55). Scrum-Poker nutzt oft eine geglättete Version, die oft «1, 2, 3, 5, 8, 13, 20, 40, 100» oder ähnlich lautet.
Die Folge eignet sich hervorragend, weil sie der Tatsache Rechnung trägt, dass es zwar relativ einfach ist, auszusagen, dass eine Aufgabe doppelt oder dreifach so groß wie eine andere ist, dass es aber kaum eine sinnvolle Aussage ist, zu diskutieren, ob eine Schätzung 39 oder 40 Mal einer anderen Aufgabenstellung entspricht. So entsprechen die größeren Abstände dem Wunsch, markante Unterschiede formulieren zu können und darüber zu diskutieren. Werden große Umfänge geschätzt, ist das oft ein Zeichen dafür, dass geprüft werden sollte, ob eine Anforderung womöglich noch in mehrere Anforderungen (z.B. mehrere User-Stories) unterteilt werden kann, um für das Entwicklungsteam einfacher handhabbare Portionen zu gestalten.
Manche Organisationen ziehen Schätzungen in T-Shirt-Grössen (XS, S, M, …) oder auch idealen Tagen und Stunden (in der Annahme, das Team könne zu 100% seiner Zeit an der Arbeit sitzen und würde nicht gestört werden) vor.
Eine Möglichkeit, Schätzungen einfacher zu gestalten, stellt die Triangulation dar. Dabei werden die zu schätzenden Stories mit zwei unterschiedlich grossen Stories verglichen. Eine Referenzstory hat dabei beispielsweise 1 Story-Point und eine andere 10. Durch den Vergleich mit 2 Referenzen fällt das Schätzen manchen Menschen leichter.
Affinity Estimation
Schätzungen mit Scrum-Poker sind oft etwas aufwendig, bieten dafür aber den Vorteil, dass sich das Entwicklungsteam im Schätzprozess über Umsetzungsmögichkeiten austauschen und dabei einen optimalen Ansatz finden kann. Liegt das Ziel eher darin, innerhalb relativ kurzer Zeit einen Überblick über eine große Anzahl von User-Stories zu gewinnen, wie dies oft gerade zu Projektbeginn der Fall ist, bewährt sich Affinity Estimation (in Deutsch: «Ähnlichkeitsschätzung»).
Bei der Affinity Estimation werden die Anforderungen (meist in Form von User-Stories) ihrem Umfang folgend geordnet. User-Stories mit geringem Umsetzungsaufwand werden links angeordnet, solche mit größerem rechts. Für jede User-Story wird bestimmt, ob sie größer, kleiner oder gleich umfangreich wie jede andere ist, wodurch sich eine nach dem Umsetzungsaufwand sortierte Folge ergibt. Diese Stories werden anschließend noch gruppiert und den Elementen jeder Gruppe die jeweils gleiche Anzahl an Story-Points zugeordnet.
Geschwindigkeit (Velocity)
Bei der Geschwindigkeit (Velocity) zählen nur 100% fertiggestellte Stories. Sie wird berechnet aus der Anzahl Story Points dividiert durch die Anzahl Sprints.
Die Möglichkeit, den Umsetzungsaufwand von Anforderungen zu schätzen, bildet die Grundlage für agile Planung. Damit das Team im Sprint-Planungsmeeting eine passende Anzahl von User-Stories auswählt, sind zwei Informationen notwendig. Zum einen muss eine Vorstellung darüber bestehen, welche Umsetzungskapazität in Story-Points das Team pro Sprint hat. Diese Information lässt sich relativ einfach gewinnen, indem die Summe der Story-Points der vollständig umgesetzten User- Stories durch die Anzahl der abgeschlossenen Sprints dividiert wird. Nicht vollständig fertiggestellte User-Stories (solche, welche nicht der Definition of Done entsprachen und entsprechend zurück in den Product Backlog fielen) werden mit «0» gezählt.
Beispielrechnung:
Es wurden bislang in 12 Sprints 136 User-Stories umgesetzt.
Geschwindigkeit (Velocity) = 136 / 12 = 11.33 ➔ Die Geschwindigkeit beträgt 11.
Gerade zu Beginn einer neuen Produktentwicklung bestehen oft noch keine belastbaren Vorstellungen zur Teamgeschwindigkeit. In solchen Fällen wird entweder eine Annahme getroffen oder wo es Vorabinformationen gibt (z.B. Geschwindigkeit desselben Teams in einem vergleichbaren früheren Projekt), können diese benutzt werden. Auch ist damit zu rechnen, dass die Teamgeschwindigkeit in den ersten Sprints oft noch schwer vorhersagbar ist, da in vielen Fällen Fragen der Zusammenarbeit im Team, aber auch Fragen zum Produktumfang noch nicht ganz klar sind, was zu erheblichen Schwankungen führen kann. Im Verlauf weiterer Sprints werden Schätzungen und Angaben zur Geschwindigkeit immer zuverlässiger und belastbarer.
Wichtig ist, anzumerken, dass Angaben zur Geschwindigkeit immer teamspezifisch sind. Unterschiedliche Teams können sehr unterschiedliche Geschwindigkeiten haben, was teils darauf basiert, dass Referenzstories unterschiedlich sind, andererseits aber auch damit zusammenhängen kann, dass Teamkonstellationen und Anforderungen voneinander abweichen.
