Agile Schätzung: Der umfassende Leitfaden
Ein praktischer Leitfaden zur agilen Schätzung: User Stories, Planning Poker, Story Points, Velocity und die Techniken, die sich bewähren, wenn sich eine Story als umfangreicher herausstellt, als zunächst angenommen.
Planning Poker ist eine auf Konsens basierende agile Schätzmethode: Die Teams stimmen geheim ab, decken alle Karten gleichzeitig auf und diskutieren die Streuung der Schätzungen, bis sich diese annähern.
So führen Sie eine Planning-Poker-Runde durch, die aussagekräftige Schätzungen liefert, ohne sich in die Länge zu ziehen: Vorbereitung, die vier Phasen der Runde, die Auswahl eines Kartensatzes und striktes Zeitmanagement.
Story-Points dienen dazu, den relativen Aufwand, die Komplexität und die Unsicherheit einer Aufgabe zu messen – nicht die Arbeitsstunden. Wie man den Umfang anhand einer Referenz-Story einschätzt und welche Fragen Teams dabei vor Probleme stellen.
Die Story-Points steigen von 1, 2, 3, 5, 8 auf 13, da die sich vergrößernden Abstände Unsicherheit widerspiegeln – die Skala gibt nicht länger vor, man könne einen 13er von einem 14er unterscheiden. Hier erfahren Sie, warum gerade diese Abstände entscheidend sind.
Story-Punkte messen den relativen Aufwand; Stunden messen die Dauer – es handelt sich um unterschiedliche Größenordnungen. Wenn Sie eine Umrechnungstabelle von Punkten in Stunden erstellen, sind Sie still und leise wieder zur Zeiteinschätzung zurückgekehrt.
Die Velocity ist der durchschnittliche Wert der Story-Punkte, die ein Team pro Sprint abarbeitet. Wozu sie dient, warum sie in dem Moment versagt, in dem sie zum Ziel wird, und wie man sie realistisch hält.
Menschen können nur schwer einschätzen, „wie lange etwas dauern wird“, sind aber gut darin, zu beurteilen, „ob etwas größer ist als das andere“. Bei der relativen Einschätzung wird Letzteres herangezogen – und genau deshalb funktionieren Story-Points.
Frühe Schätzungen weisen große Schwankungsbreiten auf, weil das Projekt noch unbekannt ist, und nicht, weil Ihr Team schlecht im Schätzen ist. Was der „Kegel der Unsicherheit“ bedeutet und wie man ihn eingrenzen kann – statt ihn noch weiter auszudehnen.
Epics, Stories und Aufgaben sind drei Ebenen mit jeweils drei Aufgaben. Was diese jeweils bedeuten, welche davon Story-Punkte tragen und warum die Fokussierung auf die falsche Ebene die Velocity bedeutungslos macht.
Agile Schätzverfahren im Vergleich – Planning Poker, T-Shirt-Sizing, Buckets, Dot Voting, Affinity und Magic Estimation sowie die jeweiligen Schwachstellen jeder Methode.
Die häufigsten Fehler bei der Durchführung von Planning-Poker-Sitzungen – Mittelwertbildung bei den Karten, Schätzungen in Stunden, als Druckmittel eingesetzte Velocity, Story-Point-Inflation – und wie man diese jeweils beheben kann.
Akzeptanzkriterien sind der „Bestanden/Nicht bestanden“-Test einer Story, der vor Beginn der Arbeit festgelegt wird – die Formate, die funktionieren, Beispiele dafür sowie die Unterschiede zur Definition von „fertig“.
Die Definition von „Fertig“ besteht aus einer teamweiten Checkliste, die jede Story erfüllen muss, bevor sie ausgeliefert wird. Ein Beispiel für eine solche „DoD“, wer dafür verantwortlich ist und wie sie sich von den Abnahmekriterien unterscheidet.
Die Definition von „bereit“ ist die Checkliste, die angibt, dass eine Story sprintfähig ist. Was eine nützliche Checkliste umfasst, warum die meisten ignoriert werden und welche Version tatsächlich ein Hindernis darstellt.
Eine Geschichte, deren Umfang Sie nicht abschätzen können, ist in der Regel eine, die Sie noch nicht veröffentlichen können. Wie lässt sich erkennen, wann man sie aufteilen sollte, welche Trennlinien zu veröffentlichungsfähigen Abschnitten führen und welche nur den Anschein davon erwecken?
SPIDR umfasst fünf bewährte Methoden zur Aufteilung einer User Story: Spike, Pfad, Schnittstelle, Daten und Regeln. Wann funktioniert die jeweilige Aufteilungslinie, und wann führt sie zu einer unechten Aufteilung?
Vertikale Schnitte liefern Mehrwert; horizontale Schnitte liefern Versprechen. Warum eine Aufteilung nach Technologieebenen den Mehrwert verzögert und wie man nach Nutzerergebnissen aufteilt, damit in jedem Sprint etwas fertiggestellt wird.
Eine User Story ist ein kurzes, in einfacher Sprache formuliertes Wertversprechen. Das „Rolle-Ziel-Nutzen“-Format, die drei Cs, die INVEST-Checkliste und die Fälle, in denen User Stories das falsche Werkzeug sind.
Sechzehn Beispiele für User Stories aus den Bereichen Authentifizierung, E-Commerce, Mobile, APIs und Fehlerbehebung – jedes davon mit Anmerkungen versehen, wobei die fehlerhaften Versionen neben den überarbeiteten Fassungen dargestellt sind, sodass der Unterschied deutlich wird.
Die klassische Vorlage für eine User Story mit einer „Kopieren-Einfügen“-Karte, die wissenswerten Varianten sowie ein ausgearbeitetes Beispiel, das von der Vorlage über die Akzeptanzkriterien bis hin zur Schätzung geführt wird.