User Story Die Basis agiler Anforderungen

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Die User Sto­ry ist ein zen­tra­les Ele­ment für die Arbeit in agi­len Pro­jek­ten und für das agi­le → Requi­re­ments Engi­nee­ring.
In die­sem Bei­trag wird der Auf­bau und Ein­satz von User Sto­ries kurz beschrieben.

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 User Sto­ries und auch die Gren­zen des sinn­vol­len Ein­sat­zes von User Stories.

Erläu­te­run­gen zu den User Sto­ries sind häu­fig in den Beschrei­bun­gen von → Scrum ent­hal­ten, die aber den­noch all­ge­mein­gül­tig sind.

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 erreichen”.”

Abbil­dung 1.1: User Sto­ry: Schema

Die Beschrei­bung in die­ser Form wird auch als “Role-→ Fea­ture-Reason-Sche­ma” bezeichnet.

Bei­spie­le für User Stories:

• “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önnen”
• “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”

Anmer­kung zur Schreib­wei­se:
In die­sem Bei­trag wer­den “User Sto­ry” (Sin­gu­lar) und “User Sto­ries” (Plu­ral) genau so geschrie­ben. Dies wird bei eini­gen ande­ren Autoren anders gehand­habt, bei mir aber durch­gän­gig in allen Bei­trä­gen und → Prä­sen­ta­tio­nen so verwendet.

1.1 Definitionen

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

• In der Wiki­pe­dia steht zu User Sto­ries /#Wiki-User-Story/:
  “Eine User Sto­ry (“Anwen­der­er­zäh­lung”) ist eine in All­tags­spra­che for­mu­lier­te Soft­ware-Anfor­de­rung. Sie ist bewusst kurz­ge­hal­ten und umfasst in der Regel nicht mehr als zwei Sätze.”
• 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 Kunden.”
• 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 → Stake­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, son­dern die­nen in ers­ter Linie der Kom­mu­ni­ka­ti­on.
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/

1.3 Die Rollen bei den User Stories

Auch wenn die Rol­len, Rol­len­be­zeich­nun­gen “frei” gewählt wer­den kön­nen, so emp­fiehlt es sich, die­se aus der Stake­hol­der­lis­te abzu­lei­ten. Hier­durch ergibt sich fast auto­ma­tisch eine → Prio­ri­sie­rung der User Sto­ries, da Sto­ries, die wich­ti­gen Stake­hol­dern zuge­ord­net sind, bereits “wich­tig” sind.

Fall­stri­cke:

• Häu­fig zu fin­den ist die For­mu­lie­rung “Als Benut­zer möch­te ich …”: Benut­zer sind — genau wie Kun­den — zwar eine Stake­hol­der­rol­le, aber in vie­len Kon­tex­ten zu unspe­zi­fisch. Daher ist es sinn­voll, hier bei Bedarf dies wei­ter zu detail­lie­ren, so bei­spiels­wei­se “Gele­gen­heits­be­nut­zer” oder “Dau­er­be­nut­zer” zu unterscheiden
• Wenn bei User Sto­ries die “höchs­te Ent­schei­dungs­in­stanz” wie “Geschäfts­füh­rer”, “Vor­stand” oder “der Geschäfts­be­reich” ver­wen­det, so muss dies a) über­prüf­bar blei­ben und b) eher spar­sam gesche­hen, da ansons­ten sol­che User Sto­ries als har­te Vor­ga­ben gese­hen wer­den und damit kei­nen Spiel­raum für die Umset­zung lassen

1.4 Akzeptanzkriterien

→ Akzep­tanz­kri­te­ri­en, die bei der Abnah­me der umge­setz­ten User Sto­ry getes­tet wer­den, müs­sen zu jeder User Sto­ry notiert werden.

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önnen.

2.1 Die Story Card

Eine User Sto­ry wird übli­cher­wei­se auf eine 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.

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

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-)→ Lis­te realisiert.

Zur Ver­tie­fung kann die eigen­stän­di­ge Beschrei­bung der → Defi­ni­ti­on of Done her­an­ge­zo­gen werden.

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 den Deve­l­o­pern 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önnten.

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 Eigenschaften:

• 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
• Valuable: User Sto­ries sol­len einen Wert für den Kun­den haben
• Esti­mata­ble: User Sto­ries sol­len schätz­bar sein
• Small: User Sto­ries sol­len klein sein
• Test­a­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 werden.

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: Eine Visi­on gilt für ein zu ent­wi­ckeln­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­wi­ckeln­de Pro­dukt / die zu ent­wi­ckeln­de Dienst­leis­tung auf einer grob-gra­nu­la­ren Ebene
• 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 Anwenders
• Task: Ein 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

Abbil­dung 3.1: Die Pyra­mi­de des Agi­len Requi­re­ments Engineerings

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 (und soll­ten daher auf meh­re­re Sprints ver­teilt werden).
• kön­nen (noch­mals) in klei­ne­re User Sto­ries unter­teilt werden.
• wer­den für eine spä­te­re Zukunft geplant.
• sind eine Zusam­men­fas­sung meh­re­rer, ver­wand­ter User Stories.
• kön­nen even­tu­ell nicht abge­schätzt werden.

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

3.2 Die User Story Map

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

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 hergestellt.”

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 Stake­hol­der) abgeleitet.

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 Stake­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 Ebenen.”

4. Häufig gestellte Fragen und Antworten (FAQ) zur User Story

Eini­ge Fra­gen zur User Sto­ry / zu den User Sto­ries wer­den häu­fig gestellt – die­se wer­den hier wie­der­ge­ge­ben und beantwortet.

• 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 empfohlen.
• 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 Ver­wen­dung 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 erstellen.
• F: Gibt es ver­schie­de­ne Arten von User Sto­ries?
  A: Ja, so wird zum Teil zwi­schen Manage­ment- und Deve­lo­per-User-Sto­ries unter­schie­den. Manage­ment-User-Sto­ries beschrei­ben Sich­ten “des Manage­ments”, häu­fig ein­fa­che Manage­ment-Vor­ga­ben. Aber Ach­tung: User Sto­ries müs­sen durch Ent­wick­ler umsetz­bar sein. 

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

Von hoher Rele­vanz zum The­ma User Sto­ries sind mei­ne fol­gen­den Präsentationen:

Inhalt	Typ
Agi­li­tät: Agi­les Requi­re­ments Engi­nee­ring – Eine Übersicht
Agi­li­tät: Scrum – Eine Kurzübersicht
Agi­li­tät: Scrum – Eine Übersicht
Agi­li­tät: Scrum – Die Literatur(liste)
Agi­li­tät: Scrum-Zer­ti­fi­zie­run­gen – Eine Kurzübersicht
Agi­li­tät: Per­so­nas – Eine Übersicht

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. /Bergsmann23/ Johan­nes Berg­s­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 3. Auf­la­ge 2023, ISBN 978–3‑86490–929‑0
6. /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
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

• /INVEST-03/ Ori­gi­nal-Arti­kel zu INVEST von Bill Wake (2003)
• /OB­Jspek-RE-2016/ Objekt­Spek­trum 02/2016: Moni­ka Schu­bert: Von der Impact Map zu User-Sto­rys: Wie Stake­hol­der und Ent­wick­ler gemein­sam eine Stra­te­gie verfolgen
• /Scrum-Glos­s­ar/ Das deut­sche Scrum-Glos­sar
• /#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
• /#Wiki-User-Story/ User Sto­ry in der deut­schen Wikipedia
• /#Wiki-User-Story‑e/ User Sto­ry in der eng­li­schen Wikipedia

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: 02.04.2020 © Peter­jo­hann Con­sul­ting, 2005–2024