User Stories Die Basis agiler Anforderungen

Mit User Sto­ries (zu Deutsch etwa „Anwen­der­ge­schich­ten”) kön­nen Anfor­de­run­gen an (zukünf­ti­ge) Pro­duk­te oder Dienst­leis­tun­gen von (poten­zi­el­len) Nut­zern oder Kun­den auf ein­fa­che Wei­se beschrie­ben und erfasst wer­den.
Sie kön­nen damit ein wesent­li­cher Bestand­teil bei der Erstel­lung von Pro­duk­ten oder Dienst­leis­tun­gen sein, ins­be­son­de­re wenn eine agi­le Vor­ge­hens­wei­se (wie Scrum) ver­wen­det wird.
Obwohl das Kern­kon­zept der User Sto­ries sehr ein­fach ist, erge­ben sich in der Pra­xis eini­ge zusätz­li­che Aspek­te, die es zu beach­ten gilt. Hier­zu zäh­len die Nach­voll­zieh­bar­keit durch Drit­te, die Grö­ße der ein­zel­nen Sto­ries und auch die Gren­zen des sinn­vol­len Ein­sat­zes von User Sto­ries.

Manage­ment-Zusam­men­fas­sung zu die­sem Bei­trag:
User Sto­ries sind ein zen­tra­les Ele­ment für die Arbeit in agi­len Pro­jek­ten.
In die­sem Bei­trag wer­den die User Sto­ries kurz beschrie­ben.

Die all­ge­mei­ne Beschrei­bung zu Scrum fin­det sich
hier


1. Einleitung und Grundlagen

Im Scrum-Glos­sar /Scrum-Glos­s­ar/ steht zur User Sto­ry:
“Eine in “nor­ma­ler Spra­che” for­mu­lier­te Anfor­de­rung, typi­scher­wei­se auf einer Kar­te (Sto­ry Card) beschrie­ben — meis­tens in der Form
“Als Rol­le
möch­te ich Ziel/Wunsch
um Nut­zen zu errei­chen”.”

User Stories: Schema, (C) Peterjohann Consulting, 2019-2020

Abbil­dung 1.1: User Sto­ries: Sche­ma

Die Beschrei­bung in die­ser Form wird auch als “Role-Fea­ture-Rea­son-Sche­ma” bezeich­net.

Bei­spie­le für User Sto­ries:

  • “Als Web­site-Besu­cher möch­te ich inner­halb von weni­gen Sekun­den erken­nen, wer der Betrei­ber der Web­site ist, um die Serio­si­tät ermit­teln zu kön­nen”
  • “Als Anwen­der möch­te ich den Stand der Prä­sen­ta­ti­on erken­nen, um so zu erfas­sen, ob die aktu­el­le Ver­si­on ver­wen­det wird”
  • “Als Taxi-Nut­zer möch­te ich vor­ab dar­über infor­miert wer­den, wie hoch die Kos­ten für eine Fahrt zu mei­nem Ziel sind, um so sicher zu sein, dass ich die Fahrt bezah­len kann”

1.1 Definitionen

Fol­gen­de Defi­ni­tio­nen beschrei­ben User Sto­ries:

  • In der Wiki­pe­dia steht zu User Sto­ries /#Wiki-User-Story/:
    “Eine User Sto­ry (“Anwen­der­erzäh­lung”) ist eine in All­tags­spra­che for­mu­lier­te Soft­ware-Anfor­de­rung. Sie ist bewusst kurz gehal­ten und umfasst in der Regel nicht mehr als zwei Sät­ze.”
  • Mike Cohn for­mu­liert /Cohn10/:
    “Eine User Sto­ry beschreibt eine Funk­tio­na­li­tät, die ent­we­der für einen User oder einen Käu­fer eines Sys­tems oder einer Soft­ware von Wert ist.”
  • Bei Wir­de­mann fin­det sich /Wirdemann17/:
    “User Sto­ries sind in der Spra­che des Anwen­ders for­mu­lier­te Anfor­de­run­gen an das zu ent­wi­ckeln­de Soft­ware-Sys­tem. Die­se Anfor­de­run­gen besit­zen einen kon­kre­ten und sicht­ba­ren Mehr­wert für den Kun­den.”
  • In BABOK Gui­de /BBG17‑d/ steht:
    “Eine User Sto­ry ist eine kurz­ge­fass­te, prä­zi­se Beschrei­bung der Funk­tio­na­li­tät oder Qua­li­tät, die benö­tigt wird, um einem spe­zi­fi­schen Sta­ke­hol­der von Nut­zen zu sein.”

1.2 Einschränkungen

User Sto­ries die­nen der Erfas­sung von Anfor­de­run­gen. Sie haben aber kei­nen “gesetz­lich-bin­den­den” Cha­rak­ter.
Hier­zu schrei­ben eini­ge Autoren:

  • “User Sto­ries sind kei­ne ver­trag­li­chen Ver­pflich­tun­gen.” /Cohn10/
  • “A user sto­ry is not­hing more than an agree­ment that the cus­to­mer and deve­lo­pers will talk tog­e­ther about a fea­ture.” /Beck01/

2. User Stories im Einsatz

Auch wenn das Grund­prin­zip der User Sto­ries ein­fach erscheint, so erge­ben sich in der Pra­xis eini­ge Pro­ble­me, die durch Hilfs­mit­tel gelöst wer­den kön­nen.

2.1 Die Story Card

Eine User Sto­ry wird übli­cher­wei­se auf ein Kar­te (“Sto­ry Card”, z.B. im DIN-A5- oder DIN-A6-For­mat) geschrie­ben und an ein Task Board gehängt, wo sie wei­ter­be­ar­bei­tet wird.

Eine User Story, (C) Peterjohann Consulting, 2014-2020

Abbil­dung 2.1: Eine User Sto­ry (Bei­spiel mit Sto­ry Card)

Der Auf­wand zur Umset­zung der User Sto­ries wird geschätzt und in Sto­ry Points ange­ge­ben.

2.2 Definition of Done

Die Defi­ni­ti­on of Done (DoD) beschreibt (im Vor­hin­ein), wann eine umge­setz­te User Sto­ry als fer­tig gilt, das heißt, vom Anwen­der abge­nom­men wer­den kann. Die (uni­ver­selle) Über­prü­fung der DoD-Kri­te­ri­en fin­det nach der voll­stän­di­gen Erstel­lung der User Sto­ry statt. Übli­cher­wei­se wird die DoD über eine (Check-)Liste rea­li­siert.

Eine ver­tie­fen­de Beschrei­bung zur Defi­ni­ti­on of Done fin­det sich
hier

Zeitliche Einordnung der Definition of, (C) Peterjohann Consulting, 2019-2020

Abbil­dung 2.2: Zeit­li­che Ein­ord­nung der “Defi­ni­ti­on of”

2.3 Definition of Ready

Ist eine User Sto­ry geschrie­ben, so soll sie auch in die Umset­zung gelan­gen. Um sicher­zu­stel­len, dass sie auch eine gewis­se Qua­li­tät besitzt, die es dem Ent­wick­lungs­team erlaubt ohne zu gro­ßen Auf­wand die Umset­zung vor­zu­neh­men, wird eine Defi­ni­ti­on of Rea­dy (DoR) ver­wen­det, die über­grei­fend für alle User Sto­ries gilt. Hier­über wird gere­gelt, wel­chen Vor­ga­ben eine User Sto­ry fol­gen muss.
Gera­de bei Akzep­tanz- und Test­kri­te­ri­en tre­ten in der Pra­xis häu­fig Pro­ble­me auf: Hier kann die Defi­ni­ti­on of Rea­dy hel­fen.
Die Defi­ni­ti­on of Rea­dy ist kein all­ge­mei­ner Stan­dard und unter Fach­ex­per­ten umstrit­ten, da schrift­lich for­mu­lier­te Regeln auch auf man­gel­haf­te Kom­mu­ni­ka­ti­on hin­deu­ten könn­ten.

2.4 Die INVEST-Kriterien

(Gute) User Sto­ries haben Eigen­schaf­ten, die den INVEST-Vor­ga­ben fol­gen (/INVEST-03/, /Cohn10/). Dabei steht das Akro­nym INVEST für fol­gen­de Eigen­schaf­ten:

  • Inde­pen­dent: User Sto­ries sol­len unab­hän­gig von­ein­an­der sein
  • Nego­tia­ble: User Sto­ries sol­len ver­han­del­bar sein
  • Valu­able: User Sto­ries sol­len einen Wert für den Kun­den haben
  • Esti­mat­a­ble: User Sto­ries sol­len schätz­bar sein
  • Small: User Sto­ries sol­len klein sein
  • Testa­ble: User Sto­ries sol­len test­bar sein

3. User Stories im Großen

User Sto­ries beschrei­ben ein­zel­ne Funk­tio­na­li­tä­ten. Um gro­ße Sys­te­me zu beschrei­ben, kön­nen User Sto­ries in einen über­ge­ord­ne­ten Kon­text ein­ge­ar­bei­tet wer­den.

3.1 Die Pyramide des Agilen Requirements Engineerings

Die unter­schied­li­chen Betrach­tungs­hö­hen der ein­zel­nen Glie­de­rungs­ebe­nen beim Agi­len Requi­re­ments Engi­nee­ring kön­nen über eine Pyra­mi­de dar­ge­stellt wer­den (sie­he Abbil­dung 3.1).

Es fin­den sich:

  • Visi­on: Ein Visi­on gilt für ein zu ent­wick­len­des Pro­dukt / eine zu ent­wi­ckeln­de Dienst­leis­tung und beschreibt, was mit dem Pro­dukt erreicht wer­den soll
  • The­me: Ein The­me beschreibt das zu ent­wick­len­de Pro­dukt / die zu ent­wi­ckeln­de Dienst­leis­tung auf einer grob-gra­nu­la­ren Ebe­ne
  • Epic / Fea­ture: Ein Epic oder ein Fea­ture ist eine “gro­ße” oder “grob-gra­nu­la­re” User Sto­ry, die auf­grund ihrer Grö­ße nicht direkt umge­setzt wer­den kann. Sie­he hier­zu Abschnitt 3.1.1
  • User Sto­ry: Der zen­tra­le Begriff — Eine User Sto­ry beschreibt eine ein­zel­ne Anfor­de­rung aus Sicht des Anwen­ders
  • Task: Eine Task ist eine Auf­ga­be, die nicht mehr unter­teilt wer­den kann / muss, da sie eine für das Ent­wick­ler­team pas­sen­de Grö­ße zur Umset­zung / Bear­bei­tung hat

Die Pyramide des Agilen Requirements Engineerings, (C) Peterjohann Consulting, 2019-2020

Abbil­dung 3.1: Die Pyra­mi­de des Agi­len Requi­re­ments Engi­nee­rings

3.1.1 Epics

Als Epi­cs wer­den User Sto­ries bezeich­net, die “sehr groß” oder “grob-gra­nu­lar” sind.
Dies kann bedeu­ten:
Epi­cs …

  • sind zu groß, um in einem Sprint umge­setzt wer­den zu kön­nen.
  • kön­nen (noch­mals) in klei­ne­re User Sto­ries unter­teilt wer­den.
  • wer­den für eine spä­te Zukunft geplant.
  • sind eine Zusam­men­fas­sung meh­re­rer, ver­wand­ter User Sto­ries.
  • kön­nen even­tu­ell nicht abge­schätzt wer­den.

Um Epi­cs in User Sto­ries “run­ter­zu­bre­chen” kann die Sto­ry Decom­po­si­ti­on ein­ge­setzt wer­den.

3.2 Die User Story Map

Eine User Sto­ry Map zeigt die Zusam­men­hän­ge von meh­re­ren User Sto­ries.

In der Wiki­pe­dia steht zu zur Sto­ry Map /#Wiki-User-Story/:
„Eine Sto­ry Map zeigt User Sto­ries in einer gra­fi­schen Über­sicht. Hori­zon­tal wer­den die auf­ein­an­der­fol­gen­den Akti­vi­tä­ten des Anwen­ders jeweils mit einer User Sto­ry dar­ge­stellt. Ver­ti­kal wird von oben nach unten detail­liert: z.B. ange­fan­gen bei den Kun­den­zie­len über Epi­cs bis hin zu den User Sto­ries. Durch eine Sto­ry Map wird ein Über­blick über alle User Sto­ries her­ge­stellt.“

Die Story Map, (C) Peterjohann Consulting, 2019-2020

Abbil­dung 3.2: Die Sto­ry Map

3.3 Impact Mapping

Beim Impact Map­ping wer­den User Sto­ries von Zie­len (der Sta­ke­hol­der) abge­lei­tet.

In /#ObjektSpek-16/ steht:
„Impact Map­ping ist ein Kom­mu­ni­ka­ti­ons­mit­tel, wel­ches das gegen­sei­ti­ge Ver­ständ­nis zwi­schen Sta­ke­hol­dern und Ent­wick­lern för­dert und unter­schied­li­che Per­spek­ti­ven zulässt. Es dient als stra­te­gi­sches Pla­nungs­in­stru­ment und besteht aus vier Ebe­nen.“


4. Häufige Fragen und Antworten zum Thema “User Stories”

Eini­ge Fra­gen zu User Sto­ries wer­den häu­fig gestellt – die­se wer­den hier wie­der­ge­ge­ben und beant­wor­tet.

  • F: Sind die User Sto­ries ver­pflich­tend, wenn man agil arbei­ten möch­te?
    A: Nein, aber es wer­den gene­rell User Sto­ries bei agi­ler Vor­ge­hens­wei­se emp­foh­len.
  • F: Wer ist für die Erstel­lung der User Sto­ries ver­ant­wort­lich?
    A: Im agi­len Kon­text ist dies immer der Pro­duct Owner.
  • F: Kann man aus User Sto­ries ein Las­ten­heft erstel­len?
    A: Eigent­lich nicht, da die Betrach­tungs­wei­se eine ande­re ist. Ein Las­ten­heft soll­te mög­lichst voll­stän­dig ein Pro­dukt oder eine Dienst­leis­tung beschrei­ben, eine Samm­lung von User Sto­ries hat die­sen Anspruch nicht.
  • F: Ist die Defi­ni­ti­on von Per­so­nas für User Sto­ries not­wen­dig?
    A: Nein, aber sie kön­nen hilf­reich sein, um die User Sto­ry zu erstel­len.

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 öffentliche Präsentation zu den User Stories

Die Prä­sen­ta­ti­on ist in wei­ten Tei­len deckungs­gleich mit der Dar­stel­lung auf die­ser Web­site und kann für eine “Schnell­dar­stel­lung” genutzt wer­den.

InhaltVer­si­onStandSei­tenGrö­ßeTyp

Eben­falls von hoher Rele­vanz zum The­ma User Sto­ries sind mei­ne fol­gen­den Prä­sen­ta­tio­nen:

InhaltVer­si­onStandSei­tenGrö­ßeTyp
Agi­li­tät: Agi­les Requi­re­ments Engi­nee­ring – Eine Über­sicht0.1005/2014840,8 MB pdf (pdf)
Agi­li­tät: Scrum – Eine Kurz­über­sicht0.8006/2018200,4 MB pdf (pdf)
Agi­li­tät: Scrum – Eine Über­sicht0.8006/2018700,7 MB pdf (pdf)
Agi­li­tät: Scrum – Die Literatur(liste)0.8006/2018340,3 MB pdf (pdf)
Agi­li­tät: Per­so­nas – Eine Über­sicht0.2006/2018480,5 MB pdf (pdf)

A.2 Literatur

  1. /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
  2. /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‑99308810–0
  3. /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
  4. /Beck00/ Kent Beck, Mar­tin Fow­ler: Plan­ning Extre­me Pro­gramming, Addi­son-Wes­ley Pro­fes­sio­nal, Addi­son-Wes­ley Pro­fes­sio­nal, Old Tap­pan, New Jer­sey 2000, ISBN 978–0‑201–71091‑5
  5. /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 zur erfolg­rei­chen Umset­zung, dpunkt, Hei­del­berg 2. Auf­la­ge 2018, ISBN 978–3‑86490–149‑2
  6. /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
  7. /Cohn10a/ 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
  8. /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
  9. /Patton14/ Jeff Pat­ton: User Sto­ry Map­ping: Dis­co­ver the Who­le Sto­ry, Build the Right Pro­duct, O’Reil­ly Media, Cam­bridge, Mas­sa­chu­setts 2014, ISBN 978–1‑4919–0490‑9
  10. /Patton15/ Jeff Pat­ton: User Sto­ry Map­ping: Nut­zer­be­dürf­nis­se bes­ser ver­ste­hen als Schlüs­sel für erfolg­rei­che Pro­duk­te, O’Reil­ly, Köln  2015, ISBN 978–3‑95875–067‑8
  11. /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

Legen­de zu den Web­links
/ / 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 Web­site
/#V/ Ver­weis auf ein Video auf einer Web­site


Scroll to Top