Was sind Story Points?

Story Points sind eine Maßeinheit zur Einschätzung des Gesamtaufwandes, der für die vollständige Umsetzung eines Product Backlog Items oder einer anderen Arbeit nötig ist.

Wenn wir etwas mit Story Points einschätzen, geben wir jedem Item eine gewisse Punktzahl. Die Rohwerte sind dabei nicht weiter wichtig. Es sind die relativen Werte, um die es geht. Eine Story, die mit 1 Punkt eingeschätzt wird, sollte also halb so groß sein wie eine Story, die mit 2 Punkten eingeschätzt wird. Eine Story mit 3 Punkten sollte daher dreimal so groß sein wie die Story mit 1 Punkt.

Statt Werte wie 1, 2 oder 3 zu benutzen, könnte ein Team auch 100, 200 und 300 Punkte vergeben – oder 1 Million, 2 Millionen und 3 Millionen. Es geht einzig und allein um das Verhältnis der Zahlen zueinander und nicht um die Zahlen an sich.

Welche Faktoren fließen in die Einschätzung mit Story Points mit ein?

Da Story Points den Entwicklungsaufwand einer Story repräsentieren, muss alles in die Einschätzung des Teams miteinfließen, was diesen Aufwand beeinflussen könnte, wie z. B.:

• Die Menge an zu erledigender Arbeit
• Die Komplexität dieser Arbeit
• Jegliche Risiken oder Ungewissheiten bei der Erledigung dieser Arbeit

Bei einer Einschätzung mit Story Points sollten Sie jeden dieser Faktoren einkalkulieren. Lassen Sie uns gemeinsam schauen, wie die einzelnen Faktoren die Aufwandseinschätzung beeinflussen können.

Die Menge an zu erledigender Arbeit

Wenn man viel erledigen muss, sollte die Aufwandseinschätzung natürlich größer ausfallen. Stellen wir uns einmal vor, wir würden zwei Webseiten entwickeln. Die erste Seite hat nur ein Feld und ein Label, um einen Namen einzutragen. Die zweite Seite hat 100 Felder, die auch einfach nur mit ein wenig Text gefüllt werden sollen.

Die zweite Seite ist komplexer als die erste. Es gibt keine Interaktion zwischen den einzelnen Feldern und jedes besteht lediglich aus ein wenig Text. Es gibt keine zusätzlichen Risiken auf dieser zweiten Seite. Der einzige Unterschied zwischen den beiden Seiten ist, dass es auf der zweiten Seite mehr Arbeit gibt.

Die zweite Seite sollte demnach mehr Story Points bekommen. Obwohl es dort zwar ungefähr 100 Felder mehr gibt, bekommt die Seite nicht unbedingt 100-mal mehr Punkte. Skaleneffekte sorgen nämlich dafür, dass die Seite nur zwei-, drei- oder 10-mal so viel Aufwand ist wie die erste Seite.

Risiko und Ungewissheit

Die Risiken und die Ungewissheit bei einem bestimmten Product Backlog Item sollten die Einschätzung des Items beeinflussen.

Wenn ein Team gebeten wird, eine Einschätzung für ein Product Backlog Item vorzunehmen, und der Stakeholder, der danach gefragt hat, nicht genau sagen kann, was er benötigt, dann sollte sich diese Ungewissheit in der Einschätzung widerspiegeln.

Komplexität

Auch die Komplexität sollte bei einer Einschätzung mit Story Points in Betracht gezogen werden. Denken Sie noch einmal an das Beispiel mit der Webseite mit 100 einfachen Textfeldern, zwischen denen es keinerlei Interaktion gibt.

Nehmen wir nun eine weitere Webseite mit 100 Feldern. Allerdings sind einige davon für das Eintragen eines Datums gedacht, bei denen sich eine Kalenderansicht öffnen soll. Einige dieser Felder sind formatierte Textfelder für Telefonnummern oder Sozialversicherungsnummern. Andere Felder führen eine Prüfsummenvalidierung für z. B. Kreditkartennummern durch.

Bei diesem Screen werden Interaktionen zwischen den einzelnen Feldern benötigt. Wenn ein Nutzer als Kreditkarte eine Visa Card angibt, wird ein dreistelliges CVV-Feld für die Kartenprüfnummer angezeigt.

Auch wenn es immer noch nur 100 Felder auf dieser Seite gibt, sind sie dennoch schwerer zu implementieren, denn sie sind komplexer und benötigen daher auch mehr Zeit. Außerdem ist hier die Wahrscheinlichkeit größer, dass ein Entwickler einen Fehler macht und im Nachhinein diesen Fehler korrigieren muss.

Diese zusätzliche Komplexität sollte sich in den Einschätzungen widerspiegeln.

Alle Faktoren beachten!

Es mag unmöglich erscheinen, mit einer einzigen Zahl drei verschiedene Faktoren wiederzugeben und mit dieser eine Einschätzung abzugeben. Es ist aber tatsächlich möglich, denn es gibt einen Faktor, der alle anderen Faktoren vereint – der Aufwand. Diejenigen, die eine Einschätzung vornehmen, überlegen sich, wie viel Aufwand es sein wird, die durch ein Product Backlog Item beschriebene Menge an Arbeit zu erledigen.

Sie überlegen, wie viel Aufwand es wohl sein wird, mit den Risiken und der Ungewissheit dieses Product Backlog Items umzugehen. Normalerweise tut man dies, indem man die Risiken eines auftretenden Problems und dessen potenzielle Auswirkungen abwägt. Eine Einschätzung wird also beispielsweise bei einem zeitaufwendigen Risiko, das außerdem auch noch sehr wahrscheinlich ist, höher sein als bei einem geringeren und unwahrscheinlicheren Risiko.

Zudem wird die Komplexität der zu erledigenden Arbeit einkalkuliert. Komplexe Arbeiten erfordern eventuell genauere Überlegungen, Experimentieren auf Trial-and-Error-Basis und mehr Austausch mit dem Kunden. Vielleicht dauert die Validierung auch länger und man benötigt mehr Zeit für die Korrektur von Fehlern.

Daher müssen alle drei Faktoren kombiniert werden.

Das Konzept von Story Points

Eine Einschätzung mit Story Points muss alles beinhalten, was benötigt wird, um ein Product Backlog Item auf done zu setzen. Wenn die Definition of Done eines Teams das Erstellen von automatisierten Tests für die Validierung einer Story voraussetzt (was eine gute Idee wäre), dann sollte der Aufwand für diese Tests in die Einschätzung miteinfließen.
Das Konzept von Story Points in seiner Gänze zu begreifen, kann durchaus schwierig sein. Aber es wird die Mühe wert sein, zu verstehen, dass Punkte stellvertretend sind für Aufwand und dass dieser Aufwand durch die Menge an Arbeit, Komplexität und Risiken bzw. Ungewissheit eines Product Backlog Items beeinflusst wird.