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.
Schätzungen gehen auf bekannte Weise schief: Zahlen, die für verschiedene Personen unterschiedliche Bedeutungen haben, Sitzungen, die überziehen, Prognosen, denen niemand vertraut. Die Lösung liegt selten in einer besseren Formel – vielmehr in einem gemeinsamen Verständnis, das das gesamte Team teilt, und in Schätzungen, die als Prognosen betrachtet werden und nicht als Verpflichtungen, die Ihnen später vorgehalten werden.
Dieser Leitfaden behandelt die Elemente, die sich in der Praxis bewährt haben – User Stories, Planning Poker, Story Points, Velocity sowie die Techniken, die auch dann noch funktionieren, wenn sich eine Story als umfangreicher herausstellt, als es zunächst den Anschein hatte. Wenn Sie bereit sind, mit Ihrem Team eine Schätzung durchzuführen, nutzen Sie die Schätzfunktion in TeamRetro: Planning Poker mit vertraulicher Abstimmung, wiederverwendbaren Kartensätzen und endgültigen Story-Punkten, die direkt mit Ihrem Backlog synchronisiert werden.
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.
Erfahren Sie, was die Team-Velocity in agilen Methoden ist, wie man sie berechnet und wie man Sprints damit plant – inklusive eines kostenlosen Velocity-Rechners.
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 – nicht, weil Ihr Team schlecht im Schätzen ist. Was der „Kegel der Unsicherheit“ bedeutet und wie man ihn eingrenzt – 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.
Ein praktischer Leitfaden zur Auswahl agiler Schätzverfahren: Planning Poker, Story Points, T-Shirt-Sizing, Affinitätsschätzung und Velocity – sowie Hinweise dazu, wann welches Verfahren zum Einsatz kommen sollte.
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 aus der Praxis und wie sie sich von der Definition von „fertig“ unterscheiden.
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 jede dieser Trennlinien, und wann führt sie zu einem unechten Ausschnitt?
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 verfasstes 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 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.
Was die T-Shirt-Größen bedeuten, wie man eine Sitzung durchführt und wie man S/M/L in Story-Points umrechnet – sowie wann Planning Poker die bessere Wahl ist.