Unsere Entwicklungsteams schätzen den Aufwand für eine User Story in der Regel auf Basis von Story Points. Die meisten Kunden können mit dieser Messgröße erstmal nichts anfangen, weil sie Schätzungen in Zeit (Stunden) oder Geld (Euro) gewöhnt sind. Wir wollen Ihnen deshalb kurz erklären, warum wir Story Points in Aufwandsschätzungen verwenden und wie Schätzungen auf Basis von Story Points zu verstehen sind.

Story Points als Messgröße für Komplexität

Story Points sind ein Maß für Komplexität. Wenn einem Entwicklungsteam eine Aufgabe vorgelegt wird, bespricht es diese mit dem Product Owner oder Kunden, bis inhaltlich klar ist, was genau umgesetzt werden soll. Anschließend macht das Team sich Gedanken darüber, wie die Aufgabe technisch implementiert werden kann und welche sonstigen Aufwände entstehen. Um den Aufwand für die Beschätzung in Grenzen zu halten und nicht zu viele technische Details im Vorfeld ohne Not festzulegen, schätzt das Team, wie komplex die Aufgabe ist. Dafür nutzt es Story Points.

Weil das Team noch nicht genau weiß, wie es die Aufgabe umsetzen und welches Teammitglied daran arbeiten wird, kann es keine genaue Aussage über den Aufwand treffen. Vielleicht entpuppt sich ein vorgesehener Lösungsweg als nicht gangbar, vielleicht wird ein erfahrenes Teammitglied krank, vielleicht stellt der Kunde kurzfristig besondere Ansprüche an die Qualität, vielleicht passiert irgendetwas unvorhersehbares. Eine genaue Zeitschätzung ignoriert diese ganzen Wenns und Abers und suggeriert eine Vorhersehbarkeit, die es in der Praxis in der Regel nicht gibt. 

Welche Ausprägungen haben Beschätzungen mit Story Points? 

Anders als Stunden oder Euro sind Story Points eine abstrakte Größe, die sich an der Fibonacci-Reihe orientieren. Sie können eine Ausprägung von 1, 2, 3, 5, 8, 13, 20, 40 und 100 haben. (Die eigentliche Fibonacci-Reihe kennt einige dieser Werte nicht, deshalb handelt es sich um eine Abwandlung). User Stories mit sehr vielen Story Points (20 oder mehr) bedeuten, dass das Team diese Story für sehr komplex hält und sie für eine realistische Beschätzung in kleinere Stories aufgeteilt werden muss. User Stories mit wenigen Story Points bedeuten, dass das Team die Komplexität gut einschätzen kann. 

Bei der Beschätzung mit Story Points verwendet das Team eine User Story, die in der Vergangenheit bereits umgesetzt wurde, als Referenzgröße. Das Team weiß folglich, dass es für eine bestimmte User Story eine bestimmte Anzahl an Story Points geschätzt hat und vergleicht die neuen User Stories mit dieser, um einen Vergleichsmaßstab zu haben.

Umrechnungskurse und Ungenauigkeiten

Ihr Kundenbetreuer wird Ihnen immer den aktuellen "Umrechnungskurs" für Story Points mitteilen. Für alle User Stories, die wir umsetzen, messen wir, wie teuer diese sind und können so einen ziemlich genauen Wert berechnen, der aussagt, wie teuer ein Story Point in einem bestimmten Team im Durchschnitt ist. Als Kunde können Sie sich bei Ihrer Budgetplanung daran orientieren. Mehr als eine Orientierung kann der Umrechnungskurs aber leider nicht sein. Das hat mehrere Gründe: 

• Manche Stories erweisen sich bei der Umsetzung als komplexer oder weniger komplex als angenommen; darüber informieren wir Sie zeitnah und stimmen das weitere Vorgehen mit Ihnen ab.
• Eine Beschätzung auf Basis von Story Points ist ungenau, insbesondere bei den höheren Werten. 13 Punkte bedeutet mehr als 8 aber weniger als 20. Für eine Erhöhung der Schätzgenauigkeit für die zu erwartenden Aufwände eignet sich in diesem Fall ein weiteres Herunterbrechen auf kleinere Stories. Siehe hierzu auch unser Video über kontinuierliches Schätzen in agilen Projekten.
• Referenzwerte aus anderen Projekten können ungenau sein, weil Rüstzeiten, die technologische Infrastruktur, Kommunikationsaufwände, Testumgebungen etc. sich von Projekt zu Projekt unterscheiden; all das sind Faktoren, die mit der eigentlichen Aufgabe im engeren Sinne wenig zu tun haben und sich deshalb oft schwer im Vorfeld beschätzen lassen.

Weiterführende Informationen:

• Agile Vorhersagen: Story Points und agile Schätzverfahren
• Kontinuierliche Schaetzungen in agilen Projekten