Agiles Schätzen Schnell und passend Schätzungen vornehmen

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).

Klassisches und Agiles Schätzen, (C) Peterjohann Consulting, 2021-2022

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:

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.

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. 

Ein Planning-Poker-Kartenset, (C) Peterjohann Consulting, 2021-2022

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.

Ein Planning-Poker-Kartenset: Bedeutung der einzelnen Werte, (C) Peterjohann Consulting, 2021-2022

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. Es 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.

Magic Estimation: Bewertungschema, (C) Peterjohann Consulting, 2021-2022

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 wer­den Schät­zun­gen auf Basis bereits gemach­ter Erfah­run­gen vorgenommen.

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ß)

3. Häufige Fragen und Antworten 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

pdf

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 Examp­le: How Suc­cess­ful → 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
  • /Bergsmann18/ Johan­nes Bergs­mann: Requi­re­ments Engi­nee­ring für die agi­le Soft­ware­ent­wick­lung: Metho­den, Tech­ni­ken und Stra­te­gien, dpunkt, Hei­del­berg 2. Auf­la­ge 2018, ISBN 978–3‑86490–485‑1
  • /Cohn04/ Mike Cohn: User Sto­ries App­lied: 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­ma­ting 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­d­ance 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­fingwell: 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
  • /Pichler16/ Roman Pich­ler: Stra­te­gi­ze: Pro­duct Stra­te­gy 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 2016, ISBN 978–0‑9934992–0‑3
  • /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

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

  • /IREB-22/, /#IREB-22/, /#IREB-CPRE-FL-22/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Lehr­plan / Syl­labus zum CPRE-FL, Ver­si­on 3.1.0 vom Sep­tem­ber 2022 (deutsch, pdf-Datei, 50 Seiten)
  • /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-22/ 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.0 vom Dezem­ber 2022 (deutsch, pdf-Datei, 111 Seiten)
  • /IREB-Agi­le-Pri­mer-20/, /#IREB-Agile-Primer-20/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Lehr­plan / Syl­labus zum CPRE RE@Agile Pri­mer, Ver­si­on 1.1.0 vom Sep­tem­ber 2020 (deutsch, pdf-Datei, 67 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 Suther­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 Suther­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 Suther­land – deut­sche Über­set­zung, aktua­li­siert im Novem­ber 2020

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