Agiles Schätzen Schnell und passend Schätzungen vornehmen

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Unter “Agi­les → Schät­zen” (engl. Agi­le Esti­ma­ti­on) wird eine Rei­he von → Schätz­me­tho­den ver­stan­den, die ihren Ursprung in der agi­len → Soft­ware­ent­wick­lung haben, inzwi­schen aber auch in ande­ren Kon­tex­ten ein­ge­setzt wer­den. Beim Agi­len Schät­zen wer­den Anfor­de­run­gen, die typi­scher­wei­se in Form von → User Sto­ries erfasst wur­den, abge­schätzt.
In die­sem Bei­trag wird das “Agi­le Schät­zen” beschrieben.

Agi­les Schät­zen kann als Spiel­art des Schät­zens gese­hen wer­den und steht damit gleich­ran­gig neben dem klas­si­schen Schät­zen (Abbil­dung 0.1).

Abbil­dung 0.1: Klas­si­sches und Agi­les Schätzen

1. Einleitung und Grundlagen

Das Schät­zen ist ein Kom­mu­ni­ka­ti­ons­mit­tel, um bei Agi­ler Vor­ge­hens­wei­se Anfor­de­run­gen / User Sto­ries abzuschätzen.

1.1 Wer schätzt?

Im Agi­len Kon­text schätzt das “Team” — hier­un­ter wer­den ins­be­son­de­re die Ent­wick­ler wie auch der → Pro­duct Owner verstanden.

1.2 Wann wird geschätzt?

Schät­zun­gen erfol­gen im Schätz­mee­ting (Esti­ma­ti­on → Mee­ting), wel­ches in fes­ter Tak­tung in einem Sprint stattfindet.

1.3 Was wird geschätzt?

User Sto­ries kön­nen geschätzt wer­den nach:

• → Kom­ple­xi­tät
• Risi­ko
• (→ Auf­wand)
• …

1.4 Die Maßeinheit der Schätzungen

Sto­ry Points sind ein Schätz­maß für die Grö­ße einer → User Sto­ry. Übli­cher­wei­se wer­den Sto­ry Points nicht in abso­lu­ten Grö­ßen ange­ge­ben, son­dern in einem rela­ti­ven Maß.

“Sto­ry Points sind eine Ein­heit, die die Grö­ße einer User Sto­ry beschreiben.”

User Sto­ries soll­ten so groß sein, dass sie inner­halb eines Sprints umge­setzt wer­den kön­nen, d.h. inner­halb von ein bis vier Wochen. Wenn also eine User Sto­ry eine Sto­ry Point Grö­ße hat, die es nicht mehr erlaubt, die User Sto­ry in einem Sprint zu bear­bei­ten, so muss sie unter­teilt / “geschnit­ten” werden.

Häu­fig wer­den auch T‑Shirt-Grö­ßen zur Grö­ßen­an­ga­be ein­ge­setzt. Dabei wer­den (zumin­dest) die T‑Shirt-Grö­ßen S, M, L und XL verwendet.

1.5 Merkregeln zum Agilen Schätzen

Fol­gen­den Sprü­che und Merk­re­geln gel­ten für das Agi­le Schätzen:

• “Das Schät­zen ist wert­voll, die → Schät­zung nicht” (Mike Cohn?)
• “Eine Schät­zung ist gut, wenn sie nicht mehr als um 50 % abweicht”

2. Methoden

Fol­gen­de Metho­den wer­den beim Schät­zen in agi­len Vor­ge­hen angewandt:

1. Plan­ning Poker
2. Magic Esti­ma­ti­on
3. Bucket Esti­ma­ti­on
4. Affi­ni­ty Estimation

2.1 Planning Poker

Plan­ning Poker (Schätz­po­ker) ist eine Schätz­me­tho­de zum Abschät­zen einzel­ner User Sto­ries, die das gan­ze Team ein­be­zieht. Hier­zu wird ein Schätz­mee­ting durch­ge­führt, bei dem jedes Team­mit­glied ein Kar­ten­set mit 13 Kar­ten erhält (mit auf­ge­druck­ten Wer­ten von 0 bis 100, zudem noch das Fra­ge­zei­chen und die Kaf­fee­tas­se) und pro User Sto­ry eine Bewer­tung abgibt. 

Abbil­dung 2.1: Ein Planning-Poker-Kartenset

Die Sto­ry Points wer­den in rela­ti­ven Maßen ange­ge­ben — die Bedeu­tung der ein­zel­nen Wer­te ist in Abbil­dung 2.2 wiedergegeben.

Abbil­dung 2.2: Ein Plan­ning-Poker-Kar­ten­set: Bedeu­tung der ein­zel­nen Werte

Es wird beim Schätz­mee­ting (Esti­ma­ti­on Mee­ting) eine Tisch­run­de gebil­det, an dem alle Team­mit­glie­der sit­zen. Jedes Team­mit­glied ver­fügt über ein Planning-Poker-Kartenset.

Nun wird die zu schät­zen­de User Sto­ry in die Tisch­mit­te gelegt und kurz (durch den Pro­duct Owner) erläu­tert. Dann gibt jedes Team­mit­glied eine Schät­zung ab, indem eine ver­deck­te Kar­te mit dem geschätz­ten Wert auf den Tisch gelegt wird. Haben alle Team­mit­glie­der ihre Schät­zung abge­ge­ben, wer­den alle Kar­ten gleich­zei­tig aufgedeckt.

Nach dem Auf­de­cken der Kar­ten wird geschaut, ob gro­ße Abwei­chun­gen in der Ein­schät­zung vor­han­den sind. Wenn nicht, so wird der häu­figs­te Schätz­wert über­nom­men und auf die Sto­ry Card ein­ge­tra­gen. Sind aber erheb­li­che Unter­schie­de zu erken­nen, so muss über die­se unter­schied­li­chen Bewer­tungen dis­ku­tiert wer­den. Bei gro­ßen Abwei­chun­gen kann nach der Dis­kus­si­on eine erneu­te Schät­zung (in einer wei­te­ren Schätz­run­de) vor­ge­nom­men wer­den, sodass ein abschlie­ßen­der Wert ermit­telt wer­den kann.

2.2 Magic Estimation

Magic Esti­ma­ti­on ist eine wei­te­re Schätz­me­tho­de in der agi­len Welt, die sich neben dem Plan­ning Poker eta­bliert hat. Sie dient ins­be­son­de­re dazu, grö­ße­re Back­logs abzu­schät­zen, da es eine schnell durch­führ­ba­re Metho­de ist und somit vie­le → Back­log Items in kur­zer Zeit abge­schätzt wer­den können.

Die Durch­füh­rung ist ähn­lich wie beim Plan­ning Poker: Es wer­den User Sto­ries von den Team­mit­glie­dern in einem Schätz­mee­ting abgeschätzt.

In dem Schätz­mee­ting wer­den die abzu­schät­zen­den User Sto­ries durch den Pro­duct Owner vor­ge­stellt und jede User Sto­ry an ein ein­zel­nes Team­mit­glied wei­ter­ge­reicht. Wenn alle User Sto­ries (gleich­mä­ßig) ver­teilt sind, beginnt jedes Team­mit­glied mit der Abschätzung.

Hier­zu wer­den die Sto­ry Cards (User Sto­ries) in ein Ras­ter (Sto­ry Points in einer Ska­la, ver­glei­che Plan­ning Poker) ein­ge­ord­net, wel­ches typi­scher­wei­se auf dem Fuß­bo­den oder an Flip­charts unter­ge­bracht ist.

Abbil­dung 2.3: Magic Esti­ma­ti­on: Bewertungsschema

Nun wird das Team aktiv: Jedes Team­mit­glied über­prüft, ob es den ein­zel­nen Abschät­zun­gen zustimmt. Sto­ries mit abwei­chen­der Schät­zung wer­den her­aus­ge­nom­men (“her­aus­ge­scho­ben”), anschlie­ßend im gesam­ten Team dis­ku­tiert und erneut zugeordnet.

Es gilt dabei zu beach­ten (“Spiel­re­geln”):

• Wäh­rend des Zuord­nens darf nicht mit­ein­an­der gespro­chen werden
• Jedes Team­mit­glied darf die User Sto­ries so oft ver­schie­ben, wie es möchte
• Die größ­te Zahl (oder das ?) wird dafür genutzt, um nicht-ver­ständ­li­che / nicht-abschätz­ba­re User Sto­ries zu markieren

2.3 Bucket Estimation

Die Bucket Esti­ma­ti­on ähnelt der Magic Esti­ma­ti­on sehr stark: Es wer­den Eimer (Buckets) mit unter­schied­li­chen Bewer­tun­gen auf­ge­stellt und die Team­mit­glie­der ord­nen die User Sto­ries den Eimern zu.

2.4 Affinity Estimation

Bei der Affi­ni­ty Esti­ma­ti­on (Affi­ni­täts­schät­zung) wer­den Schät­zun­gen auf Basis bereits gemach­ter Erfah­run­gen vorgenommen.

2.5 Weitere agile Schätzverfahren

Es gibt wei­te­re agi­le Schätz­ver­fah­ren, die in die­sem Bei­trag aber nicht beschrie­ben wer­den — die­se sind:

• Wall Esti­ma­ti­on: Dies ist im Prin­zip die Magic Estimation
• Team Esti­ma­ti­on Game: Das Abschät­zen erfolgt auf Basis von User Sto­ries, die ein­zeln nach­ein­an­der durch Team­mit­glie­der gezo­gen und dann (ver­glei­chend) abge­schätzt werden 
• Fibo­nac­ci Esti­ma­ti­on / Fibo­nac­ci-Schät­zung: Dies ist ein ande­re Begriff für das Plan­ning Poker

3. Der Umgang mit den Schätzergebnissen

Wenn die Schät­z­er­geb­nis­se da sind, …

• die­nen sie als Basis für die Aus­wahl des nächs­ten Sprint Backlogs.
• soll­ten sie nicht zur Auf­wands- oder Kos­ten­er­mitt­lung her­an­ge­zo­gen werden.

Merk­re­geln:

• Pro Sprint nur eine (begrenz­te Anzahl) Sto­ry mit hohem Risi­ko nehmen
• Anzei­chen, dass etwas schief­ge­lau­fen ist: Sto­ry Points mit Kom­ma (z.B. als empi­ri­sches Maß)

4. Häufig gestellte Fragen und Antworten (FAQ) zum Agilen Schätzen

Eini­ge Fra­gen zum Agi­len Schät­zen wer­den häu­fig gestellt – die­se wer­den hier wiedergegeben.

• F: Wel­che Metho­de für das Agi­le Schät­zen ist die bes­te?
  A: Hier­zu gibt es kei­ne ein­deu­ti­ge Antwort.
• F: Kann man auf das Agi­le Schät­zen ver­zich­ten?
  A: Über­ra­schen­der­wei­se lau­tet die Ant­wort: Ja. Es gibt den “No-Estimates”-Ansatz, der sich damit beschäf­tigt, war­um auf Schät­zun­gen (im agi­len Kon­text) ver­zich­tet wer­den kann.

Haben Sie noch wei­te­re Fra­gen oder möch­ten Sie Ergän­zun­gen an der FAQ vor­neh­men? Am bes­ten schrei­ben Sie mir hier­zu eine E‑Mail an: kontakt@peterjohann-consulting.de.

A. Präsentationen, Literatur und Weblinks

A.1 Meine Präsentationen

Die Beschrei­bung des Agi­le Schät­zens ist in Tei­len in mei­ner Prä­sen­ta­ti­on zum Agi­len → Requi­re­ments Engi­nee­ring (ARE) ent­hal­ten. Die­se kann hier her­un­ter­ge­la­den werden.

Inhalt	Typ
Agi­li­tät: Agi­les Requi­re­ments Engi­nee­ring – Eine Übersicht

A.2 Literatur

In fol­gen­den Büchern wird als Aspekt das Agi­le Requi­re­ments Engi­nee­ring erläutert:

• /Adzic11/ Goj­ko Adzic: Spe­ci­fi­ca­ti­on by Exam­p­le How Suc­cessful → Teams Deli­ver the Right Soft­ware, Man­ning Publi­ca­ti­ons, Green­wich, Con­nec­ti­cut 2011, ISBN 978–1‑61729–008‑4
• /Adzic12/ Goj­ko Adzic: Impact Map­ping. Making a Big Impact with Soft­ware Pro­ducts and Pro­jects, Pro­vo­king Thoughts, Woking, Gre­at Bri­tain 2012, ISBN 978–0‑9556836–4‑0
• /Adzic14/ Goj­ko Adzic, David Evans: Fif­ty Quick Ide­as to Impro­ve Your User Sto­ries, Neu­ri Con­sul­ting, Lon­don 2014, ISBN 978–0‑9930881–0‑0
• /BBG15/ → IIBA: A Gui­de to the → Busi­ness Ana­ly­sis Body of Know­ledge (BABOK Gui­de), Inter­na­tio­nal Insti­tu­te of Busi­ness Ana­ly­sis, Mari­et­ta, Geor­gia 3rd Edi­ti­on 2015, ISBN 978–1‑927584–02‑6
• /BBG17‑d/ IIBA: BABOK v3: Leit­fa­den zur Busi­ness-Ana­ly­se BABOK Gui­de 3.0, Dr. Götz Schmidt, Wet­ten­berg 2017, ISBN 978–3‑945997–03‑1
• /Cohn04/ Mike Cohn: User Sto­ries Appli­ed. For Agi­le Soft­ware Deve­lo­p­ment, Addi­son-Wes­ley Long­man, Ams­ter­dam 2004, ISBN 978–0‑321–20568‑1
• /Cohn05/ Mike Cohn: Agi­le Esti­mat­ing and Plan­ning, Pren­ti­ce Hall Inter­na­tio­nal, Upper Sadd­le River, New Jer­sey 2005, ISBN 978–0‑13–147941‑8
• /Cohn09/ Mike Cohn: Suc­cee­ding with Agi­le. Soft­ware Deve­lo­p­ment Using → Scrum, Addi­son-Wes­ley Long­man, Ams­ter­dam 2009, ISBN 978–0‑321–57936‑2
• /Cohn10/ Mike Cohn: User Sto­ries. Für die agi­le Soft­ware-Ent­wick­lung mit Scrum, XP u.a., mitp, Bonn 2010, ISBN 978–3‑8266–5898‑3
• /Ebert19/ Chris­tof Ebert: Sys­te­ma­ti­sches Requi­re­ments Engi­nee­ring. Anfor­de­run­gen ermit­teln, doku­men­tie­ren, ana­ly­sie­ren und ver­wal­ten, dpunkt, Hei­del­berg 6. Auf­la­ge 2019, ISBN 978–3‑86490–562‑9
• /Gloger14/ Boris Glo­ger: Wie schätzt man in agi­len Pro­jek­ten – oder wie­so Scrum-Pro­jek­te erfolg­rei­cher sind, Han­ser, Mün­chen 2014, ISBN 978–3‑446–43910‑8
• /Gloger16/ Boris Glo­ger: Scrum. Pro­duk­te zuver­läs­sig und schnell ent­wi­ckeln, Han­ser, Mün­chen 5. Auf­la­ge 2016, ISBN 978–3‑446–44723‑3
• /Girvan17/ Lyn­da Gir­van, Debra Paul: Agi­le and Busi­ness Ana­ly­sis. Prac­ti­cal Gui­dance for IT Pro­fes­sio­nals, BCS, The Char­te­red Insti­tu­te for IT, Lon­don 2017, ISBN 978–1‑78017–322‑1
• /Hruschka19/ Peter Hrusch­ka: → Busi­ness Ana­ly­sis und Requi­re­ments Engi­nee­ring. Pro­zes­se und Pro­duk­te nach­hal­tig ver­bes­sern, Han­ser, Mün­chen 2. Auf­la­ge 2019, ISBN 978–3‑446–45589‑4
• /IREB21/ sie­he /Pohl21/
• /Leffingwell10/ Dean Lef­fing­well: Agi­le Soft­ware Requi­re­ments. → Lean Requi­re­ments Prac­ti­ces for Teams, Pro­grams, and the Enter­pri­se, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2010, ISBN 978–0‑321–63584‑6
• /Leyton15/ Ryland Ley­ton: The Agi­le Busi­ness Ana­lyst. Moving from Water­fall to Agi­le, Ley­ton Publi­shing, Lon­don 2015, ISBN 978–0‑692–48185‑1
• /Pichler22/ Roman Pich­ler: Stra­te­gi­ze. Pro­duct Stra­tegy and Pro­duct → Road­map Prac­ti­ces for the Digi­tal Age, Pich­ler Con­sul­ting, Wen­do­ver, Gre­at Bri­tain 2nd Edi­ton 2022, ISBN 978–0‑9934992–4‑1
• /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basis­wis­sen Requi­re­ments Engi­nee­ring. Aus- und Wei­ter­bil­dung nach → IREB-→ Stan­dard zum Cer­ti­fied Pro­fes­sio­nal for Requi­re­ments Engi­nee­ring Foun­da­ti­on Level, dpunkt, Hei­del­berg 5. Auf­la­ge 2021, ISBN 978–3‑86490–814‑9
• /Wirdemann17/ Ralf Wir­de­mann: Scrum mit User Sto­ries, Han­ser, Mün­chen 3. Auf­la­ge 2017, ISBN 978–3‑446–45052‑3

A.3 Weblinks

Auf fol­gen­de Web­links wird hier Bezug genommen:

• /IREB-Agi­le-22/, /#IREB-Agile-22/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Lehr­plan / Syl­labus zum CPRE Advan­ced Level RE@Agile, Ver­si­on 2.0.0 vom Juli 2022 (deutsch, pdf-Datei, 44 Seiten)
• /IREB-Agi­le-→ Glos­sar-21/, /#IREB-Glossar-21/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: RE@Agile Glos­sa­ry, Ver­si­on 1.0.5 vom Okto­ber 2021 (deutsch, eng­lisch, pdf-Datei, 21 Seiten)
• /IREB-Agi­le-Hand­buch-19/, /#IREB-Agile-Handbuch-23/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Hand­buch über RE@Agile nach dem IREB-Stan­dard, Ver­si­on 2.0.1 vom April 2023 (deutsch, pdf-Datei, 111 Seiten)
• /Scrum-Gui­de-20/ Der Scrum Gui­de, Web­site mit dem aktu­el­len Scrum Gui­de (Kurz­dar­stel­lung von Ken Schwa­ber und Jeff Sut­her­land) in ver­schie­de­nen Spra­chen, aktua­li­siert im Novem­ber 2020
• /#Scrum-Guide-20‑e/ Der Scrum Gui­de (eng­lisch), 14seitige Scrum-Kurz­dar­stel­lung von Ken Schwa­ber und Jeff Sut­her­land, aktua­li­siert im Novem­ber 2020
• /#Scrum-Guide-20‑d/ Der Scrum Gui­de (deutsch), 19seitige Scrum-Kurz­dar­stel­lung von Ken Schwa­ber und Jeff Sut­her­land – deut­sche Über­set­zung, aktua­li­siert im Novem­ber 2020

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (all­ge­mein)
/*/ Ver­weis auf eine Web­site, die als Ergän­zung zu einem Buch dient
/#/ Ver­weis auf ein ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website 

Letz­te Aktua­li­sie­rung: 10.04.2022 © Peter­jo­hann Con­sul­ting, 2005–2024