Aufwandsschätzung in Scrum 1
Planning Poker und Varianten 2
HINWEIS Aus lizenzrechtlichen Gründen sind in dem Handout die meisten Bilder und Grafiken entfernt worden. Ich bitte um Verständnis. 3
1. Scrum aus der Vogelperspektive 2. Aufwandsschätzung und Poker passt das zusammen? 3. Planungspoker eine neue Erfindung? 4. Varianten des Planungspoker 5. Diskussion 6. Empfehlungen 4
Luftfahrt Automobilbau 5
1 Scrum 6
Der Scrum-Prozess Sprint Planning Meeting Backlog- Einträge vom Team Sprint Backlog in Tasks zerlegt Sprint Realisierung im Sprint Product Backlog priorisiert vom Product Owner Lieferung: Produkt-Inkrement 7
2 Aufwands- schätzung und Poker 8
Geschichten als Grundlage der Aufwandsschätzung Anforderungen werden in Form von User Storys erfasst Geschichten, wie man ein System benutzt Als Sachbearbeiter möchte ich eine Übersicht über alle Verträge eines Kunden angezeigt bekommen, um mögliche Lücken im Versicherungsschutz zu erkennen. 9
Komplexität der User Storys werden durch Story Points geschätzt. Keine Schätzung von Personentagen, Stunden, Geldeinheiten! 10
Werte für die Schätzung 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, Leonardo Fibonacci (Florenz, 1180? 1241?) einer der ersten Anwender des indischen Zahlensystems in Europa 11
12 Warum Fibonacci-Zahlen? Abstände werden immer größer Damit soll ausgedrückt werden, dass die Schätzung für große Werte immer ungenauer wird. Idee: Verhältnisse kann man häufig besser schätzen als konkrete Werte Alternative: 2, 4, 8, 16, 32, 64, 128
Planungspoker (1/2) Jedes Teammitglied schätzt die Komplexität Hat dafür Karten mit den Fibonacci-Zahlen Auf Kommando deckt jeder seine Schätzung auf Legt entsprechende Karte auf den Tisch 13
Planungspoker (2/2) Wenn alle das gleiche schätzen, nimmt man den Wert Wenn die Schätzungen nahe beieinander liegen, nimmt man den höheren Wert Liegen die Werte weit auseinander, diskutiert man die Abweichungen und pokert erneut Keine Einigung: Zerlegen der Story, Tasks definieren, Spike programmieren, Schätzung verschieben 14
Beispiele für Poker-Runden 5, 5, 5 => 5 5, 8, 5 => 8 5, 8, 5, 21 => Diskussion; anschl. neue Runde 15
Ergebnis des Planning-Poker Poker Jede User Story im Product Backlog ist geschätzt. Summe der Einzelschätzungen ergibt Umfang Umfang des Projekts, gemessen in Story Points. 16
Regeln für die Schätzung Justierung auf eine User Story mittlerer Größe Obere Grenze wird festgelegt Größter Wert bedeutet: Keine Ahnung. Aber riesengroß! 17
18 Einfluss der Projektkomplexität Ergebnis der Pokerrunde: Initial Estimate Korrektur mit Drag Factor kein Dragster wird nicht schneller sondern langsamer! berücksichtigt Projektkomplexität Komplexität, Kenntnis der Domäne, Dauer der Zusammenarbeit geschätzte Komplexität erhöht sich Anwendung = Initial Estimatex (1+ Drag Factor) = Adjusted Estimate
19
Entwicklungsgeschwindigkeit Wie schnell arbeitet mein Team? Output des Teams je Sprint gemessen in Story Points = Velocity berücksichtigt Sprintkapazität Netto-Arbeitszeit zur Realisierung von User Storys 20
Projektdauer Wie schnell arbeitet das Team den Backlog ab? Faustformel: Größe Product Backlog / Velocity = Zahl notw. Sprints Wird in Scrumzur Release-Planung verwendet 21
Beispiel 450 SP (Product Backlog) / 90 SP (Team-Velocity) = 5 Sprints Interpretation Bei einer Sprintlänge von 30 Kalendertagen ergibt sich eine wahrscheinliche Projektdauer von 150 Tagen. 22
3 Planung und Poker Einordnung 23
24 Einordnung Ähnlich Breitband-Delphi aber ohne berauschende Dämpfe aus der Erdspalte Mehrere Personen schätzen und diskutieren ihre Ergebnisse Wiederholung, wenn Vorhersagen zu stark voneinander abweichen Geschätzt wird abstraktes Komplexitätsmaß wie Function-Points Verwendet Multiplikatoren wie COCOMO AEXP: Applications Exp. (Anwendungserfahrung) CPLX: Softw. Prod. Compl. (Komplexität)...
Planungspoker und Function Points Geschätzt wird von Entwicklern Geschätzt wird im Team Keine Berechnung der Projektdauer oder Produktivität auf Basis statistisch ermittelter Werte aus anderen Projekten Aufwand für Anforderungsanalyse wird nicht einbezogen Keine Grundlage für Benchmarking Größe eines Story Points nicht normiert Schätzung wird ständig angepasst Hat nicht den Anspruch, präzise zu sein 25
Warum sind Story Points und Velocityfür die Bewertung mehrerer Teams nicht geeignet? 26
4 Varianten des Planungspoker 27
Warum andere Ansätze? Zeitaufwand für PlanningPoker Poker wird als zu hoch betrachtet. Es wird doch Zeit statt Komplexität geschätzt. Schätzer beeinflussen sich gegenseitig. 28 Vorschläge 1. (Team) Estimation Game 2. Magic Estimation (auch Affinity Estimation genannt)
(Team) Estimation Game 29
Magic Estimation User Storys werden auf Teammitglieder verteilt. Erste Runde: Teammitglieder ordnen User Storys auf einem Tisch T-Shirt Shirt-Größen (XS, S, M, L, XL, XXL) zu. Zweite Runde: Jeder darf User Storys einer anderen Größe zuordnen, muss dies aber erklären. Wenn keine Einigung herbeigeführt werden kann, wird die User Story aus der Schätzung genommen. T-Shirt Shirt-Größen werden durch Fib.-Zahlen ersetzt. Vorteil: Verfahren geht schneller 30
5 Diskussion 31
Velocity Ermittlung durch 1. Mehrere Sprints ausführen 2. Historische Daten 3. Prognose Auf keinen Fall Prognose! 32
Unser Vorgehen zur Bestimmung der Velocity Zu Anforderungen, die man in einem Zeitfenster realisiert hat, User Storys formulieren Wichtig: Inklusive Test, Dokumentation, Lieferung Nachträglich Planungspoker durchführen Benötigter Zeitaufwand durch Summe der ermittelten Story Points dividieren Ergebnis: Stunden je Story Point 33
Unser Vorgehen zur Bestimmung der Velocity Velocity = Sprintkapazität / Stunden je Story Point Zeiterfassung für Sprintkapazität wichtig! 34
Drag Factor Nach Ken Schwaber empirisch fundiert Wir verwenden ihn NICHT 35
Sprintkapazität Nicht zu hoch schätzen Empfehlung: 16 Tage bei 30-Tage Tage-Sprint Wirklich realistisch? 36
Sprintkapazität wie viel Zeit z.b. für Management- Besprechungen benötigt werden Tagesgeschäft Socialising Reisetätigkeit Verwaltungsarbeiten in der Regel sehr viel weniger als 16 Tage im Monat!! 37
Aktuelle Diskussion in der Community Sind Story Points Velocity sinnvolle Konzepte? 38
6 Empfehlungen 39
Kleine und konkrete User Storys z.b. maximal 13 SP Story Points klein wählen Nachkalkulation ergibt ca. 1 SP = 1 PT Viele User Storys schätzen Schätzungen (im Zeitverlauf) vergleichen Werden ähnlich komplexe Storys gleich geschätzt? Wachsen die Schätzungen? Schätzungen immer diskutieren Referenzbeispiele z.b. für Storys mit 1, 3, 5, 8 SP Velocity und Sprintkapazität nicht schätzen Zeitaufwände messen, um Sprintkapazität zu ermitteln 40
Free your work. Durch: Dr. Oliver Linssen oliver.linssen.linssen@liantis.com 41 Liantis GmbH & Co. KG St.-Anton Anton-Straße 69-71 47798 Krefeld Fon: 0 2151 / 931 86-60 60 Fax: 0 2151 / 931 86-61 61 info@liantis.com www.liantis.com
Free your work. 42