Wie kann man User-Stories gut abschätzen?

Jeder, der mit Scrum, SAFE oder anderen agilen Methoden gearbeitet hat, die sich auf Storypoint-Schätzungen stützen, um die Komplexität eines Features zu beurteilen, weiß, wie knifflig ein Planning Poker sein kann. Gleichzeitig ist jedem schmerzlich bewusst, wie wichtig eine gute Planungssitzung ist, um einerseits sicherzustellen, dass sich das agile Team über die Akzeptanzkriterien, die Definition of Done und des Gesamtumfangs einig ist, und um andererseits dem Product Owner die Möglichkeit zu geben, eine fundierte Entscheidung zu treffen, wenn es um die Priorisierung des Rückstands geht.

Wie also macht man eine Scrum-Poker-Sitzung erfolgreich? Um das Rezept für eine erfolgreiche Planung zu verstehen, werden wir uns ansehen, was eine gut vorbereitete Benutzergeschichte ist, wie man sie präsentiert, einige Best Practices für das Pokerspiel selbst und wie man mit Diskrepanzen zwischen den Schätzungen umgeht.

Stelle vor der Schätzung sicher, dass die Benutzergeschichte "fertig" ist und diskutiert wurde

Dies mag ein einfacher Ratschlag sein, aber für eine erfolgreiche Schätzungssitzung ist es wichtig, dass das Feature oder die Benutzergeschichte, das/die wir schätzen wollen, fertig ist. Wie bereiten wir also eine Story vor? Bei Scrum geschieht dies im Allgemeinen während der Verfeinerungssitzungen, in denen der Product Owner zusammen mit der Entwicklung (und oft unter der Leitung eines Scrum-Masters) die Details der Story bespricht.

In unserem Team fängt dies damit an, dass der Product Owner in prägnanter Form darlegt, was der Benutzer tun können möchte und welchen Wert es für ihn hat. Dieser zweite Teil ist besonders wichtig, da dort ein Gefühl dafür vermitteln wird, warum das, was wir tun, wichtig ist. Die am weitesten verbreitete Struktur für eine User Story ist "Als ..., will ich ..., damit ...".

Oftmals hat der Product Owner auch einige hochrangige Akzeptanzkriterien niedergeschrieben, die dann mit dem Entwicklungsteam diskutiert werden. Vielleicht kontraintuitiv ist, dass gute Akzeptanzkriterien Bedingungen auf hoher Ebene sind, die den Kunden zufrieden stellen und es ihm erlauben würden, den definierten Wert zu erreichen, und nicht eine fein detaillierte Anforderungsbeschreibung der Lösung. Gemeinsam bespricht das Scrum-Team die Benutzergeschichte mit Blick auf die Akzeptanzkriterien und beschließt möglicherweise, einige von ihnen hinzuzufügen oder zu entfernen oder Elemente zu klären, die eindeutig außerhalb des Anwendungsbereichs liegen.

Sobald sich alle über die Akzeptanzkriterien und die Definition of Done einig sind, kann man zur eigentlichen Schätzung übergehen, in unserem Fall mit dem Scrum Poker (auch Planning Poker genannt).

Schätzen mit Scrum-Poker

Dies ist der Moment, in dem das Schätzungstool auf scrumpoker-online.org hilfreich wird. Wir empfehlen, die Sitzung zu Beginn der Verfeinerungs- oder Planungssitzung zu eröffnen und alle Mitglieder des Scrum-Teams den Raum mit der angegebenen Raum-ID betreten zu lassen. Sobald die User Story besprochen und alle Fragen beantwortet wurden, beginnen alle Mitglieder des Entwicklungsteams damit, die Komplexität der Story einzuschätzen, indem sie ihr Story-Punkte geben. Ok, Story-Punkte und Komplexität, das hört sich einfach an... aber was genau sind Story-Punkte und woher weiß ich, wie viele Story-Punkte einer Story zugewiesen werden sollten?

Story Points

Story-Punkte im Scrum sind ein abstraktes Maß, um die Komplexität der Implementierung einer Benutzergeschichte darzustellen. Im Allgemeinen hängt diese "Komplexität" natürlich mit dem Aufwand, aber auch mit dem Risiko und den vorausgesehenen Schwierigkeiten zusammen. Das Maß ist abstrakt, weil es nicht auf eine Zeiteinheit wie Personentage oder -stunden bezogen werden kann.

Scrumpoker-online.org verwendet die Fibonacci-Folge (1,2,3,5,8,13,21) zur Schätzung von Geschichten. Es ist auch sehr hilfreich, eine Referenz-Benutzergeschichte zu haben, die alle Mitglieder des Scrum-Teams gut verstehen, und ihr eine Schätzung zuzuordnen. Das Team kann dann damit beginnen, andere Benutzergeschichten zu schätzen, indem es sie mit der Referenz-Benutzergeschichte vergleicht. Wenn zum Beispiel die Referenz-Anwendergeschichte auf 3 Punkte geschätzt wurde, sollte eine Geschichte, die nur 1 Punkt hat, dreimal weniger komplex sein. Daher ist der absolute Wert der Geschichten weniger wichtig als ihre Beziehung zueinander. Und denke daran, beweglich zu bleiben und mit dem Experimentieren zu beginnen: Je mehr Geschichten das Team schätzt, desto besser wird es zurechtkommen.

Aufdecken der Schätzungen

Nachdem alle ihre Schätzungen abgegeben haben, zeigt der Product Owner oder Scrum Master die Ergebnisse, und wenn sie alle übereinstimmen, ist die Geschichte erfolgreich geschätzt worden. Wenn es andererseits einige Diskrepanzen gibt, können die Mitglieder, die am weitesten voneinander entfernt sind, anfangen zu diskutieren, warum ihre Schätzungen voneinander abweichen. Meistens ist dies ein Hinweis darauf, dass noch nicht über alles, was diese Geschichte beinhaltet, ein gemeinsames Verständnis besteht. Diese Diskussion kann zu einer Neudefinition der Akzeptanzkriterien führen, und das ist absolut normal, es handelt sich schließlich um einen iterativen Prozess.

Ok toll, ich habe jetzt eine Schätzung, aber warum ist das wichtig?

Eine gut geschätzte Geschichte hilft dem Produkteigentümer sehr dabei, besser zu beurteilen, ob der Wert einer Benutzergeschichte (oder einer neuen Funktionalität) die Komplexität und den Aufwand für ihre Implementierung wert ist. Darüber hinaus ermöglicht sie ein besseres Verständnis für die Planung eines Sprints: Nach dem ersten Sprint wird das Team genau wissen, wie viele Story-Points es erreichen konnte, so dass der folgende Sprint mit einer ähnlichen Summe von Story-Points gefüllt sein sollte. Wenn das Team an Wissen gewinnt und effizienter wird, könnte die Anzahl der Story-Punkte schneller als bisher erreicht werden. Aber dies ist der zweite Schritt - beginne erstmal mit der Schätzung während deines Planning Poker Meeting mit scrumpoker-online.org und genieße das Vergnügen, dich mit deinen Teamkollegen auf eine Schätzung zu einigen... Du wirst sehen, es wird Wunder wirken, um ein gemeinsames Verständnis dessen zu erzeugen, was erwartet wird.