Last Updated on 9. November 2022 by Klaus
Die Anwendung von Story Points ist eine gängige Methode, um Aufwände in agilen Projekten abzuschätzen.
Junge agile Teams konfrontieren mich immer wieder mit der Frage nach der Definition von Story Points.
Story Points spiegeln die Komplexität, die Schwierigkeit einer User Story wider. Die Komplexität stellt eine konstante Eigenschaft dar, welche unabhängig vom späteren Bearbeiter der Anforderung ist.
Komplexität einer User-Story ermitteln
Das Entwicklungsteam ermittelt gemeinsam – beispielsweise per Planungspoker – die Komplexität einer User Story. Jeder Teilnehmer erhält ein Satz Poker-Karten, auf denen Story Points nach der Fibonacci-Zahlenfolge aufgedruckt sind. Er ist aufgefordert, die Komplexität gemäß seinem Verständnis von der Anforderung zu schätzen, und legt die gewählte Karte verdeckt hin.
Alle Karten werden gleichzeitig aufgedeckt. Nun haben diejenigen Teammitglieder mit der höchsten und der niedrigsten Schätzung das Wort.
- Was war ihre Motivation für diese Schätzung?
- Verstehen Sie jeweils etwas anderes unter der Anforderung? Ist sie zu ungenau beschrieben?
- Sieht der Teilnehmer mit der höchsten Schätzung Risiken, die den anderen unbekannt sind?
- Hat der Teilnehmer mit der niedrigsten Schätzung bereits eine „einfache“ Lösung vor dem geistigen Auge?
Jetzt wird deutlich, dass neben der Aufwandsschätzung Story Points ein weiteres – aus meiner Sicht sehr wichtiges – Ziel verfolgen:
Das Schätzen fördert das gemeinsame Verständnis
Das crossfunktional aufgestellte Team beleuchtet den Schwierigkeitsgrad der Anforderung von vielen Seiten. Es schält sich eine präzise Anforderung heraus, welche die Definition of Ready (DoR) des Teams erfüllt.
Der Vorgang des Planungspokers wird wiederholt, bis ein einstimmiges Verständnis vorliegt. Kann das Team eine Einigung trotz mehrfacher Anläufe nicht erzielen, so ist der Produktverantwortliche gefordert, die User Story nach Rücksprache mit den Stakeholdern zu überarbeiten.
Velocity des Teams
Die Story Points aller abgeschlossenen User Stories in einem Sprint werden aufsummiert und bilden die Velocity des Teams.
Die Velocity unterliegt Schwankungen: Die Teamgröße kann sich im Laufe der Zeit ändern, Teammitglieder gehen in Elternzeit, treten ihren wohlverdienten Urlaub an etc.
Betrachtet ein neu zusammengestelltes Team den Verlauf der Velocity über einen größeren Zeitraum, so nimmt es eine Erhöhung der Velocity wahr. Was ist passiert?
Die Mitarbeiter eines neuen Teams müssen sich zunächst kennenlernen, ihren Platz im Team finden; das Team durchläuft verschiedene Teamphasen (nach Tuckman) und vollbringt Höchstleistungen in der Integrationsphase 🙂 . Die Integrationsphase geht einher mit der Selbstorganisation des Teams.
Aber seien wir ehrlich: Bäume wachsen nicht in den Himmel, die Velocity auch nicht. Ein Team hat immer wieder Phasen, in denen es nicht so produktiv unterwegs ist.
Und wie gehen wir mit Anforderungen um, die nicht komplex sind?
Sie sind einfach in der Umsetzung, jedoch zeitlich sehr aufwändig. Obwohl die Schätzung nach obiger Definition nur wenige Story Points ergibt, da der Komplexitätsgrad gering ausfällt, nimmt die Anforderung das Team zeitlich sehr in Anspruch. Die Velocity sinkt. Ein Alarmsignal für die Führungskraft; das Team ist verunsichert. Sinkt seine Produktivität?
Natürlich nicht. Auch nicht komplexe Anforderungen müssen umgesetzt werden und fordern das ganze Team.
Aus diesem Grunde nehme ich zusätzlich in meine Definition der Story Points den (Funktions-)Umfang der Anforderung auf:
Meine Definition von Story Points
Story Points spiegeln die Komplexität und den (Funktions-)Umfang einer Anforderung wider.
