Melanie König 5Minds IT- Solu5ons GmbH & Co. KG. Agile Aufwandsschätzungen

Transkript

1 Melanie König 5Minds IT- Solu5ons GmbH & Co. KG Agile Aufwandsschätzungen

2 Inhalt (1) Warum sind vernün6ige Aufwandsschätzungen so wich5g? Wie unterscheiden sich agile von klassischen Aufwandsschätzungen? Wie sieht eine op:male Vorbereitung aus? Welche Probleme können auireten? Welche Handlungsempfehlungen gibt es? Wie sieht die Rollenverteilung aus? 2

3 Inhalt (2) Es:ma:on Games: Planning Poker Team Es5ma5on Game Team Es5ma5on Game mit verteilten Teams Magic Es5ma5on Game 3

4 Warum sind vernünftige Aufwandsschätzungen so wichtig? Basis für die Priorisierung der Arbeitspakete Basis für die Auswahl der Arbeitspakete für den nächsten Sprint (Scrum) Grundlage für jegliche Aussagen, wann der Kunde welche Funk5onalität erhält Voraussetzung für das Erreichen eines realis5schen Commitments 4

5 Wie unterscheiden sich agile von klassischen Aufwandsschätzungen? agil Basis: durchdachtes, speziell aufbereitetes und strukturiertes Backlog Gesamtes Team schätzt Schätzen von Komplexitäten Abstrakte Schätzmaße klassisch Basis: Lasten-/Pflichtenheft Eine Person schätzt (i.d.r.) Schätzen von Aufwand Konkrete Schätzmaße (PT/Stunden) 5

6 Wie sieht eine op5male Vorbereitung aus? (1) Zeitpunkt und Zeitrahmen müssen feststehen Time- boxed, nicht Scope- boxed! Zu schätzende Tasks und User Stories müssen bekannt sein Kommunika5on, welche Tasks und User Stories geschätzt werden sollen Inhaltliche Klärung zwischen Team und Product Owner (Produktverantwortlicher) Geschieht oi im Rahmen eines Backlog Grooming- Mee5ngs 6

7 Wie sieht eine op5male Vorbereitung aus? (2) User Stories müssen klar formuliert sein: Als ein <User- Typ/Rolle> will ich <Ziel/Wunsch>, so dass <Grund/Nutzen> Bsp.: Als ein <Sprecher> möchte ich <einen Beamer im Raum haben>, so dass ich <einen Vortrag halten kann> Defini?on of Done muss durch Product Owner und Team festgelegt sein Klare Akzeptanzkriterien müssen durch Product Owner und Team festgelegt sein 7

8 Wie sieht eine op5male Vorbereitung aus? (3) Die Teammitglieder müssen sich damit auseinandergesetzt haben, wie viel Aufwand hinter den zu schätzenden Tasks und User Stories steckt Welche Teammitglieder benö5gt werden Technisches Know- How Urlaubsplanung etc. 8

9 Welche Probleme können auireten? (1) Die Anforderungen sind nicht klar Die User Stories sind zu groß oder zu klein geschniden Sehr große User Stories sollten heruntergebrochen werden Aber Vorsicht: Zeit/Aufwand- Rela5on im Auge behalten (nicht genügend Zeit, um zu viele zu kleine Tasks zu schätzen!) Die rich5ge Granularität für die Tasks zu finden erfordert etwas Übung und variiert mit jedem Projekt und Team! Es sollen nicht zu viele User Stories auf einmal geschätzt werden (Schätz- Mee5ngs sollen Time boxed sein!) 9

10 Welche Probleme können auireten? (2) Unzureichende Kommunika5on zwischen den Beteiligten Kein einheitliches Verständnis aller Beteiligten Regeln sind unklar 10

11 Welche Handlungsempfehlungen gibt es? (1) Größe der User Stories: Kleine User Stories sind einfacher zu schätzen als größere. Wenn das Herunterbrechen einer User Story die Unsicherheit nicht reduziert, machen auch kleinere Tasks keinen Sinn. Zeitliche Rahmenbedingungen: In agilen Projekten korrigiert man oi den Scope (Umfang), um den Zeitrahmen einzuhalten. In klassischen Projekten baut man zusätzliche Puffer ein, um das Ziel zu erreichen. 11

12 Welche Handlungsempfehlungen gibt es? (2) Team vs. Einzelkämpfer: Generell: Vertrauen in ein Team von Experten nicht in Einzelpersonen Vermeiden von Experten- Voreingenommenheit ( anchoring ) Das gesamte Team hat wesentlich mehr Erfahrung als eine einzelne Person. Unterschiedliche Erfahrungslevels der Einzelpersonen werden durch das gesamte Team kompensiert Man erreicht ein wesentlich besseres Verständnis und eine bessere Schätzung mit dem Wissen des gesamten Teams als von einem einzelnen Experten Im besten Fall sind die Personen, die schätzen, auch die, die an dem Produkt arbeiten Vertrauen auf einzelne Experten nur, wenn kein anderer Erfahrung hat 12

13 Rollenverteilung im Schätzungsprozess (1) Scrum Master/Kanban Coach: Moderator des gesamten Mee5ngs Sorgt für die Einhaltung der Regeln Zeitlicher Rahmen (Time- boxed) Sieht zu, dass das Team sich fokussiert Hält Diskussionen kurz und produk5v 13

14 Rollenverteilung im Schätzungsprozess (2) Product Owner: Schreibt die Tasks/User Stories, die geschätzt werden sollen Verantwortlich für die Auswahl der zu schätzenden Tasks/User Stories Kennt das Produkt, muss aber kein technisches Verständnis haben Sollte alle Fragen dazu beantworten können 14

15 Rollenverteilung im Schätzungsprozess (3) Team- Mitglieder/Schätzer: Sind dafür verantwortlich, Fragen zu dem Produkt und der Umsetzung zu stellen und mit dem Product Owner zu disku5eren, um ein besseres Verständnis für die Tasks/User Stories zu erlangen Geben ihre Schätzung ab 15

16 ESTIMATION GAMES 16

17 1. Planning Poker (1) Planning Poker hat das Ziel, gute Schätzungen schnell zu erreichen, nicht die bestmöglichen Schätzungen. Methode ist nicht anonym, verhindert aber somit, dass ein Einzelner alleine sich hervorhebt. In agilen Teams misst man in Komplexität und nutzt Einheiten, die für das Team funk5onieren. Beispiel: T- Shirt- Größen 17

18 1. Planning Poker (2) Basiert auf Übereins5mmung (à Konsens des Teams) Start: Product Owner liest den Schätzern/Team das Backlog Item (User Story) vor und beschreibt es Jeder Schätzer/Team hat einen Stapel Planning Poker- Karten mit den Zahlen 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100 (angelehnt an die Fibonacci- Reihe) Unterschiedliche Bedeutung der Werte abhängig davon, womit das Team schätzt: Anzahl der Story Points, ideale Tage oder sons5ge Einheiten Diskussion des Backlog Items zwischen Schätzer/Team, um alle noch offenen Fragen zu klären 18

19 1. Planning Poker (3) Wenn alles geklärt ist, sucht sich jeder Schätzer individuell und geheim eine Karte, die seine Schätzung repräsen5ert. Alle Karten werden zur gleichen Zeit aufgedeckt. Wenn alle Schätzer den gleichen Wert gewählt haben, bekommt das Backlog Item den Schätzwert, wenn nicht wird darüber disku5ert. Besonders die Schätzer mit dem höchsten und niedrigsten Wert sollen ihre Meinung mideilen. Nach beendeter Diskussion sucht sich jeder Schätzer noch einmal eine Karte und es wird erneut auf die gleiche Weise geschätzt. Der Planning Poker- Prozess wird wiederholt, bis Einigkeit unter den Schätzern herrscht. 19

20 1. Planning Poker (4) Zusammenfassend: Sehr gut geeignet für die ini5ale Product Backlog- Schätzung oder für größere Mengen zu schätzender Backlog Items Hohe Effizienz Schätzung einer großen Menge an Backlog Items in einer sehr kurzen Zeit Sehr weit verbreitet wird sehr oi genutzt, um nächsten Sprint vorzubereiten Nachteil: Es kann sein, dass solche Spiele anfangs als nicht ernst genommen werden. Das reguliert sich aber i.d.r. nach der erfolgreichen Durchführung des Spiels. 20

21 2. Team Es5ma5on Game (1) Setup: Alle User Stories/Tasks liegen auf einzelnen Story Cards verdeckt vor. Das Team ist kompled vertreten und auch der Product Owner ist anwesend. Regeln: Jemand aus dem Team nimmt sich die oberste Story, liest sie laut vor und hängt sie an die Wand. Der nächste aus dem Team nimmt die nächste Story, liest sie laut vor und hängt sie ebenfalls an die Wand. Immer mit Begründung, ob sie von der Komplexität her gleichwer5g ist, höher oder niedriger. 21

22 2. Team Es5ma5on Game (2) Ab der driden Story Card gibt es die folgenden Op5onen: 1) Ausspielen der obersten Story Card wie oben beschrieben 2) Umhängen einer bereits gespielten Karte, verbunden mit einer (kurzen!) Erklärung und ohne Diskussion 3) Aussetzen Spielende: Das Spiel ist beendet, wenn keine Story Cards mehr auf dem Tisch liegen und alle Spieler aussetzen. 22

23 2. Team Es5ma5on Game (3) Zusammenfassend: Sehr schneller Überblick über die rela5ve Komplexität des gesamten Backlogs Keine Lösungsdiskussionen für einzelne Stories Clusterbildung an der Wand à Fibonacci- Reihe Auch das Es5ma5on Game ist nur eine grobe Schätzung keine Vorhersage in die ZukunI 23

24 3. Team Es5ma5on Game mit verteilten Teams Auf beiden Seiten stehen Projektor und Laptop Skype Verbindung Screen Sharing (z.b. mit Team Viewer) Leerer Desktop User Stories/Tasks auf elektronischen Post it s (z.b. S5ckies) Besprechung der Reihenfolge mit dem Product Owner Gleiche Regeln wie beim einfachen Team Es5ma5on Game 24

25 4. Magic Es5ma5on (1) Geeignet, um eine eine Ini5ale, aussagekräiige Schätzung zu machen Der Product Owner fasst noch einmal das große Bild zusammen und stellt dann alle User Stories/Tasks einzeln vor. Der Product Owner druckt vor dem Mee5ng die einzelnen User Stories/ Tasks auf ein Blad Papier aus Auf dem Boden werden Karten mit T- Shirt- Größen ausgelegt (XS, S, M, L, XL, XXL, jeweils eine). Anschließend versammelt sich das ganze Team um den Tisch und die User Stories werden zufällig und gleichmäßig unter den Teilnehmern aufgeteilt. 25

26 4. Magic Es5ma5on (2) Erste Runde Wich?g: Diese Runde ist eine s5lle Runde! Es gibt keine Diskussionen! Alle Teilnehmer schätzen gleichzei5g. Sie lesen die ihnen zugeteilten User Stories und ordnen sie den T- Shirt- Karten zu. Der Product Owner ist verfügbar und darf zu inhaltlichen Themen befragt werden, falls notwendig. Sobald die ersten Karten auf dem Tisch liegen, entwickelt sich implizit eine Art Skala und die Teilnehmer können sich an den bereits auf dem Tisch liegenden Stories orien5eren. Die Runde ist vorbei, wenn alle User Stories auf dem Tisch liegen. Abhängig von der Anzahl der zu schätzenden Stories dauert dies in der Regel nicht länger als ein paar Minuten.

27 4. Magic Es5ma5on (3) Zweite Runde Das gesamte Team verteilt sich um den Tisch herum und betrachtet das Ergebnis. Falls jemand eine Karte einer anderen T- Shirt- Größe zuordnen möchte, darf er das tun, muss aber dem Team kurz erklären, warum er dieser Meinung ist. Auch in dieser Runde kann der Product Owner um Erläuterung gebeten werden. Sollte sich das Team bezüglich einer Karte nicht einigen können, wird sie zwecks späterer Klärung aus der Schätzung genommen. Die zweite Runde ist vorbei, sobald niemand mehr eine Karte verschieben möchte. Im letzten Schrid werden die T- Shirt- Größen mit der Scrum- Fibonacci- Sequenz ersetzt. (XS 1; S 2; M 3) 27

28 4. Magic Es5ma5on (4) Zusammenfassend: Hohe Effizienz à Die Ini5ale Schätzung wird nicht ausdisku5ert, sondern von einer einzelnen Person vorgenommen. Möglicherweise abweichende Perspek5ven andere Teilnehmer bekommt man in der zweiten Runde. Verglichen mit dem (ohnehin schon schnellen) Team Es5ma5on Game ist Magic Es5ma5on noch einmal eine Spur schneller, da man nun nicht mehr sequenziell, sondern parallel schätzt. Nachteil: In der ersten Runde dominiert das Wissen des Einzelnen. Erst in der zweiten Runde gilt das Wissen des gesamten Teams. 28

29 Fragen?

30 Kontaktdaten E- Mail: Web: hdp://

31 Glossar User Story: Einfache Beschreibung einer Aufgabe beschrieben aus der Perspek5ve der Person, die das neue Feature benutzen möchte Beispiel: Als ein <Sprecher> möchte ich <einen Beamer im Raum haben>, so dass ich <einen Vortrag halten kann>. Story Card: Enthält die ausgedruckte oder aufgeschriebene User Story Task: heruntergebrochene Aufgabe (Teil einer User Story) Es0ma0on mee0ng: Mee5ng, in dem User Stories/Tasks für den nächsten Sprint geschätzt werden Backlog: Priorisierte Liste von User Stories und Tasks des Product Owners Backlog Item: Task oder User Story Backlog Grooming: Vorbereitungsmee5ng, um alle offenen Fragen inhaltlich sowie technisch durchzusprechen, um zu wissen, was im Es5ma5on Mee5ng geschätzt werden soll

32 Glossar Scrum Master/Kanban Coach: Verantwortlich dafür, dass Scrum/Kanban gelingt; Moderiert, sorgt für die Einhaltung der Regeln und räumt Störungen aus dem Weg Product Owner: Produktverantwortlicher Team: Gruppe von Entwicklern, Designern, Testern Defini0on of Done: Checkliste von Ak5vitäten, die zu Beginn eines Projektes vom gesamten Team festgelegt wird. Auf der Checkliste können zum Beispiel Unit Tests oder Design- Richtlinien festgelegt werden. Akzeptanzkriterien: Zeigen auf, wann eine User Story fer5g ist und sie einen Mehrwert für den Kunden hat Time- boxed: Fester Zeitrahmen Scope- boxed: Fester Umfang