Lesedauer 5 Minuten

Wie im ersten Beitrag zum Thema Scrum erörtert wurde, ist es ein wesentliches Element des Scrum-Frameworks, dass ein Entwicklungsteam ungestört und selbstorganisiert arbeiten kann. Mikromanagement von Seiten des Managements ist ausdrücklich unerwünscht, und falls es dazu kommt, sollte der Scrum Master aktiv werden.

Das bedeutet aber nicht, dass das Team Narrenfreiheit hat. Denn immerhin werden im Rahmen der Sprint Planung – einem der vom Framework definierten Ereignisse – Ziele vereinbart. Aber wie wird festgelegt, was im Verlauf eines zwei- bis dreiwöchigen Sprints erreichbar ist? Ein hilfreiches Werkzeug dafür sind User Storys und Story Points.

„Let’s tell a User Story“

Dabei handelt es sich um kurze Geschichten, die in zwei oder drei Sätzen ein bestimmtes Feature beschreiben. Dabei sollen primär folgende Fragen geklärt werden:

• Was soll das Feature tun?
• Wer ist der Anwender?
• Warum ist es wichtig?

Nicht Teil von User Storys ist die Frage nach dem Wie. Die konkrete Art der Realisierung, z. B. welche Technologie dabei verwendet wird, ist allein Sache des Entwicklungsteams. Das macht die User Story zu einem Werkzeug, um den Geschäftswert zu beschreiben. Oder, anders gesagt: das, was nach außen kommuniziert wird.

Manche User Storys beschreiben große und umfangreiche Features. Diese Epics lassen sich normalerweise in mehrere und immer kleinere User Storys aufteilen, aus denen sich letztlich konkrete Tasks ableiten lassen.

Story Points

Story Points sind ein Maß für die Größe einer User Story. Dabei stellen sie jedoch keine absolute Größe dar. Ihr Zweck ist es, Vergleichbarkeit zwischen den Storys zu schaffen:

• User Story A: 3 Story Points
• User Story B: 8 Story Points

Betrachten wir nur Story A alleine, sagen uns die Story Points zunächst noch gar nichts. Erst im Vergleich wird klar, dass B fast dreimal so groß – und damit dreimal so aufwändig umzusetzen – eingeschätzt wurde.

Da es um die Schätzung von Größenordnungen geht, ist es natürlich relativ witzlos, alle natürlichen Zahlen für die Bewertung zuzulassen. Es macht zwar einen großen Unterschied, ob einer User Story mit einem oder zwei Punkten eingeschätzt wurde (immerhin eine Verdoppelung), doch zwischen 12 oder 13 Punkten spielt der Unterschied kaum mehr eine Rolle. Daher werden üblicherweise nichtlineare Zahlenreihen verwendet.

Bewährt hat sich eine abgewandelte Fibonacci-Reihe: Dabei sind bei der Vergabe von Story Points folgende Werte erlaubt: 1, 2, 3, 5, 8 und 13. Der nächste Wert der Fibonacci-Reihe wäre eigentlich 21, doch stattdessen kommt nun 20, gefolgt von 40 und 100.

In der Praxis kommen solche großen Werte nur für User Storys zum Einsatz, die als Epics gelten. Es ist dringend angeraten, diese Aufgaben auf mehrere Unter-Storys und damit kleinere Tasks zu aufzuspalten. Effektiv bearbeitet werden üblicherweise Tasks mit maximal 13 Story Points.

Die Ermittlung der Story Points: Lass uns Poker spielen!

Eine gute Vorgangsweise ist es, am Anfang eine sehr kleine User Story zu wählen, die von allen Mitgliedern des Teams verstanden wird. Dieser Story werden fix zwei Story Points zugewiesen. Die Eins wird deshalb bewusst nicht verwendet, um Raum nach unten zu lassen, falls später noch kleinere Storys kommen sollten.

Die Größe der gewählten User Story – also der Aufwand, den die Teammitglieder dafür veranschlagen – ist nun die Referenz für alle andere User Storys. Bei jedem neuen Punkt im Product Backlog schätzen die Teammitglieder nun die Größe im Vergleich zur ersten Story. Das Ziel ist es, für alle User Storys eine Bewertung zu erlangen.

Um gruppendynamische Effekte zu vermeiden, sollte jedes Mitglied des Teams seine Bewertung unbeeinflusst von den anderen Teilnehmern. Dafür wird gerne ein Vorgang genutzt, der als Planungspoker bezeichnet wird. Dafür bekommen die Teammitglieder Kärtchen mit den erlaubten Punktezahlen, z. b. die Elemente der zuvor erwähnten abgewandelten Fibonacci-Reihe.

Eine Poker-Runde beginnt damit, dass der Product Owner eine User Story vorstellt. Danach legt jedes Teammitglied die Karte mit der Punktezahl, die seiner Meinung nach die Größe am besten abbildet, verdeckt vor sich hin. Wenn sich beim gleichzeitigen Umdrehen der Karten große Unterschiede auftun, werden diese im Team diskutiert. Möglicherweise treten dadurch Unklarheiten und Verständnisprobleme zutage, die nun ausgeräumt werden können. Dann wird die Schätzung wiederholt, mit dem Ziel, einen Konsens zu erreichen.

Bei diesen Diskussionen kann der Scrum Master als Moderator mitwirken. Wenn das Entwicklungsteam sich allmählich aufeinander einspielt, werden meist nicht mehr als zwei oder drei Runden benötigt. Wichtig ist es, sich stets vor Augen zu halten, dass hier keine absoluten Aussagen (z. B. »Das schaffen wir in zwei Tagen«) getroffen werden, sondern nur relative Angaben im Vergleich zu einer Referenz.

Der Nutzen der Story Points

Auch wenn Story Points ausdrücklich keine absoluten Größen sein sollen, geben Sie dem Product Owner am Ende ein Werkzeug in die Hand, um sein Team abzuschätzen. Denn wenn die Schätzungen in sich konsistent sind, wird sich an einigen Sprints eine Größenordnung herauskristallisieren, wie viele Story Points jeweils abgearbeitet werden. Damit liefert das Team allmählich, ohne dass etwas von außen verordnet worden wäre, allmählich aus sich selbst heraus einschätzbar. Das hilft dem Team, wenn es darum geht, in der Sprint Planung festzulegen, was im nächsten Sprint passieren soll. Aber auch für den Product Owner bietet diese Schätzung eine wertvolle Basis bei der Kommunikation mit »denen da oben«.

Stell dir vor, du wirst als Product Owner zum CEO zitiert, und der stellt dir die gefürchtete Frage: »Wann ist Feature XY fertig?« Mit deinem Product Backlog kannst du diese Frage nun einigermaßen genau beantworten. Du musst nur das gewünschte Feature anhand der User Story identifizieren. Da das Backlog idealerweise auch priorisiert ist, siehst du sofort, welche Punkte zuvor abgearbeitet werden müssen. Anhand der Story Points, die dafür vergeben wurden, kannst du deine Abschätzung vornehmen.

Sagen wir, dein Team hat sich dazu entschlossen, Sprints von zwei Wochen durchzuführen. Nach einigen Sprints hat sich herauskristallisiert, dass es zwischen 100 und 120 Story Points pro Sprint abarbeiten kann. Wenn du z. B. feststellst, dass nur noch 50 Story Points offen sind, ehe das Team die gewünschte User Story bearbeitet, kannst du wie aus der Pistole geschossen antworten: »Chef, das wird innerhalb der nächsten zwei Wochen erledigt sein.«

Wenn sich die Anzahl der Punkte hingegen der 100 annähert, solltest du allmählich vorsichtiger werden: »Chef, wahrscheinlich könnten es noch vier Wochen sein.«

Aber auch bei kurzfristigen Wünschen und Änderungen bieten die Story Points dem Product Owner eine Argumentationshilfe. Stell dir vor, dein Chef beharrt darauf, dass eine User Story sofort umgesetzt werden muss. Auch hier wirfst du einen Blick ins Backlog. Denn mit dem Wissen, was das Team üblicherweise pro Sprint schafft, kannst du abschätzen, welche User Storys trotz einer Änderung noch schaffbar sind: »Chef, können wir machen. Aber dann wird sich dieses Feature hier möglicherweise zwei Wochen nach hinten verschieben. Und jenes wird sich bestimmt nicht mehr ausgehen.«

Selbst wenn der vorgezogene Punkt noch keine Bewertung erhalten hat, lässt durch die Bewertung der übrigen Storys erkennen, was auch nach der Änderung noch klappt, und welche User Storys nun zu »Wackelkandidaten« werden.

Kein Mittel zum Vergleich von Teams

Zum Abschluss eine Warnung.

Die Menge an abgearbeiteten Story Points taugt nicht dafür, verschiedene Teams miteinander zu vergleichen. Denn für jedes Team bedeutet diese Größe etwas anderes. Eine große Anzahl an Story Points sagt zunächst nur aus, dass dieses Team zu sehr feinen Abschätzungen bzw. kleinteiligen User Storys neigt. Daraus ein größeres Arbeitspensum gegenüber einem Team mit größeren Storys und folglich weniger Punkten abzuleiten, ist schlicht falsch.

Doch nur auf das einzelne Team bezogen, bietet die Verwendung von Story Points eine gute Basis für Schätzungen und Planungen.

Das könnte dich auch interessieren