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. Es geht vielmehr um ein gemeinsames Verständnis, das das gesamte Team teilt, sowie um Schätzungen, die als Prognosen betrachtet werden und nicht als Verpflichtungen, die Ihnen später angelastet 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, gemeinsam mit Ihrem Team eine Schätzung durchzuführen, nutzen Sie die Schätzfunktion in TeamRetro: Planning Poker mit vertraulicher Abstimmung, wiederverwendbare Kartensätze und endgültige Story-Points, die direkt mit Ihrem Backlog synchronisiert werden.
Planning Poker ist eine konsensbasierte 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-Sitzung durch, die aussagekräftige Schätzungen liefert, ohne sich in die Länge zu ziehen: Vorbereitung, die vierphasige Runde, die Auswahl eines Kartensatzes und striktes Zeitlimit.
Bei der Story-Point-Schätzung werden der relative Aufwand, die Komplexität und die Unsicherheit einer Aufgabe bewertet, nicht die Arbeitsstunden. Wie lässt sich der Umfang anhand einer Referenz-Story einschätzen, und welche Fragen stellen Teams vor Herausforderungen?
Die Story-Points steigen auf 1, 2, 3, 5, 8 und 13, da die sich vergrößernden Abstände Unsicherheit widerspiegeln: Die Skala gibt nicht mehr vor, dass man einen Unterschied zwischen 13 und 14 erkennen könne. 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 Dimensionen. Wenn Sie eine Umrechnungstabelle von Punkten in Stunden erstellen, sind Sie still und leise wieder dazu übergegangen, den Zeitaufwand zu schätzen.
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 das zweite Kriterium herangezogen, und genau deshalb funktionieren Story-Points.
Frühe Schätzungen weisen große Schwankungsbreiten auf, weil die Arbeit noch unbekannt ist, und nicht, weil Ihr Team schlecht im Schätzen ist. Was der „Kegel der Unsicherheit“ bedeutet und wie man ihn eingrenzt, anstatt ihn noch zu vergrößern.
Epics, Stories und Aufgaben sind drei Ebenen mit jeweils drei Aufgaben. Was jede davon ist, welche davon Story-Punkte einbringt und warum eine falsche Einstufung der 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 für eine Story, der vor Beginn der Arbeit festgelegt wird: die zulässigen Formate, konkrete Beispiele und 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 Definition, wer dafür verantwortlich ist und inwiefern 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, die man nicht einschätzen kann, ist in der Regel eine, die noch nicht veröffentlicht werden kann. Wie erkennt man, 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, Regeln. Wann funktioniert jede dieser Trennlinien, und wann führt sie zu einer unechten Aufteilung?
Vertikale Schnitte liefern Wert; horizontale Schnitte liefern Versprechen. Warum eine Aufteilung nach Technologieebenen den Wert verzögert und wie man nach Nutzerergebnissen unterteilt, damit in jedem Sprint etwas ausgeliefert wird.
Eine User Story ist ein kurzes, in einfacher Sprache verfasstes Wertversprechen. Das „Rolle-Ziel-Nutzen“-Format, die drei Cs, die INVEST-Checkliste sowie die Fälle, in denen User Stories das falsche Werkzeug sind.
Sechzehn kommentierte Beispiele für User Stories aus den Bereichen Authentifizierung, E-Commerce, Mobile, APIs und Fehlerbehebung, wobei die fehlerhaften Versionen neben den überarbeiteten Fassungen dargestellt sind, sodass der Unterschied deutlich erkennbar ist.
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.