Drei Missverständnisse rund um User Stories

Die User Sto­ry ist das viel­leicht bekann­tes­te Kon­zept aus agi­ler Soft­ware­ent­wick­lung. Lei­der ist es auch eines der am meis­ten miss­ver­stan­de­nen Kon­zep­te. Räu­men wir mal mit den drei häu­figs­ten Miss­ver­ständ­nis­sen auf: User Sto­ries sind nicht Bestand­teil von Scrum, sie sind kei­ne Mini-Spe­zi­fi­ka­tio­nen und es ist nicht der Pro­dukt Owner der sie schreibt.

User Stories sind Bestandteil von Scrum

Obwohl sich in Pro­duct Back­logs von Scrum Teams oft­mals tat­säch­lich User Sto­ries fin­den und Tools wie JIRA die Ein­trä­ge im Back­log auch so nen­nen, erwähnt der Scrum Gui­de den Begriff User Sto­ry kein ein­zi­ges Mal. Statt­des­sen ist dort nur von Pro­duct-Back­log-Ein­trä­gen als Über­be­griff von Fea­tures, Funk­tio­na­li­tä­ten, Ver­bes­se­run­gen und Feh­ler­be­he­bun­gen die Rede. 

Tat­säch­lich stammt das Kon­zept der User Sto­ry aus dem Extre­me Pro­gramming (XP), ein agi­les Ent­wick­lungs­mo­dell, das maß­geb­lich von Kent BeckWard Cun­ning­ham und Ron Jef­fries im Rah­men des C3-Pro­jekts bei Chrys­ler zwi­schen 1995 und 2000 ent­wi­ckelt wurde.

User Stories sind Spezifikationen

Gera­de in Orga­ni­sa­tio­nen, die es über Jahr­zehn­te gewohnt waren, plan­ge­trie­ben vor­zu­ge­hen fin­det sich die­ses Mus­ter häu­fig. Es gibt Anfor­de­rer oder Kun­den, die etwas wol­len und Ent­wick­ler, die etwas lie­fern sol­len. Damit die einen die ande­ren ver­ste­hen gab es frü­her dicke Kon­zep­te und heu­te eben klei­ne User Sto­ries. Was bleibt ist das schäd­li­che Kun­den-Lie­fe­ran­ten Anti-Pat­tern

User Sto­ries hei­ßen nicht ohne Grund so. Eine Sto­ry ist etwas, das man sich erzählt und über das man spricht. Eine User Sto­ry ist die Ein­la­dung zu einem Gespräch zwi­schen Nut­zer und Ent­wick­ler und kei­ne Spe­zi­fi­ka­ti­on. Die Erkennt­nis­se die­ser Unter­hal­tung wer­den natür­lich fest­ge­hal­ten, aber die­se Doku­men­ta­ti­on ist nicht die Story. 

Ron Jef­fries schlägt daher auch die For­mel der drei Cs für gute User Sto­ries vor: Card, Con­ver­sa­ti­on und Con­fir­ma­ti­on. Mit Card ist einer­seits gemeint, dass eine Sto­ry eine phy­si­sche und im wahrs­ten Sin­ne begreif­ba­re Reprä­sen­ta­ti­on in Form eines Post-Its oder einer Kar­tei­kar­te haben soll. Ande­rer­seits folgt aus dem begrenz­ten Platz auf einem sol­chen Zet­tel auch not­wen­di­ger­wei­se Kür­ze und damit Unvoll­stän­dig­keit. Die­se Kar­te ist also nur der Anfang eines Gesprächs (Con­ver­sa­ti­on). Wenn durch das Gespräch das gemein­sa­me Ver­ständ­nis erzielt wur­de, lässt sich die­ses gut for­mal in Form von Akzep­tanz­kri­te­ri­en (Con­fir­ma­ti­on) fest­hal­ten, wel­che dann die Grund­la­ge für ein test­ge­trie­be­nes Vor­ge­hen bil­den können. 

Der Product Owner schreibt die User Stories

Die­ses Miss­ver­ständ­nis fin­det sich oft in Kom­bi­na­ti­on mit dem vor­he­ri­gen. Das Kun­den-Lie­fe­ran­ten Anti-Pat­tern ver­lei­tet dazu, wie bis­her in kla­ren Ver­ant­wort­lich­kei­ten und Über­ga­ben zu den­ken. Das Ent­wick­lungs­team ist ver­ant­wort­lich für die Ent­wick­lung und erwar­tet des­halb eine was­ser­dich­te Spe­zi­fi­ka­ti­on als User Sto­ry und die muss logi­scher­wei­se der Pro­duct Owner als Stell­ver­tre­ter der Nut­zer lie­fern. Weil er das auf­grund der Fül­le der Sto­ries nicht allei­ne kann, führt das oft sogar zu gan­zen Spe­zi­fi­ka­ti­ons­teams, die Sto­ries für die Ent­wick­lungs­teams schreiben.

A user sto­ry is a pro­mi­se for a conversation.

Ali­s­ta­ir Cockburn

Wer die Sto­ry letzt­lich schreibt ist irrele­vant, wenn man sich als ein Pro­dukt­ent­wick­lungs­team begreift, wenn man also das tren­nen­de Kun­den-Lie­fe­ran­ten-Dog­ma abge­legt hat. Letzt­lich geht es eben nicht um die User Sto­ry als Arte­fakt und die Fra­ge, wer dafür ver­ant­wort­lich ist, son­dern dar­um, dass Nut­zer und Ent­wick­ler sich ver­ste­hen. Und dazu hilft es unge­mein mit­ein­an­der zu reden.

Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

6 Kommentare

Vie­len vie­len Dank für die­sen myth buster !
Das gibt mei­nem mie­sen Gefühl mit der erleb­ten Hand­ha­bung von User Sto­ries und Pro­duct Owner Ship Worte

Hal­lo Markus,
Die­se Anti­pat­terns beob­ach­te ich auch oft. Lei­der habe ich aber oft (zumin­dest bei orga­ni­sa­to­ri­scher Tren­nung von Fach­be­reich und IT) das Gefühl, dass nur die IT das Kun­den-/Lie­fe­ran­ten­ebe­ne durch Zusam­men­ar­beit erset­zen will. Der Fach­be­reich will sei­ne Kun­den­rol­le behal­ten. Alles ande­re bedeu­tet näm­lich mehr Arbeit und weni­ger Management-Kontrolle.
Viel­leicht ste­he ich aber mit die­ser Beob­ach­tung allei­ne da.
Vie­len Dank für den Beitrag.

Dan­ke für dei­nen Kom­men­tar, lie­ber Heinz. Die­se Tren­nung Fach­be­reich und IT för­dert die­se Kun­den-Lie­fe­ran­ten-Bezie­hung natür­lich – ins­be­son­de­re wenn über Jahr­zehn­te ein­ge­übt. Ich bin mir nicht sicher, wer da mehr in die­sem Anti-Pat­tern ver­haf­tet ist … ich erle­be Fach­be­rei­che, die sehr enga­giert mit­ar­bei­ten und das teil­wei­se sogar im Team als Ent­wick­ler und ich erle­be IT, die nur mit per­fek­ter Spe­zi­fi­ka­ti­on arbeiten.

Mar­kus,
vie­len lie­ben Dank für den inter­es­san­ten Artikel. 

Ich selbst darf mich stolz als Pro­duct Owner im Fach­be­reich bezeich­nen :) – und wie schon rich­tig zusam­men­ge­fasst: Ein Back­log-Ein­trag ist eine Idee, die im gemein­sa­men Gespräch (bei uns im Pro­jekt in „3‑A­mi­go-Ses­si­ons“ (PO, BA, Design, ggf. Dev)) ver­tieft wer­den. Ist das abge­schlos­sen, wer­den noch in Cucum­ber die Akzep­tanz­kri­te­ri­en hin­ter­legt und so ist es sicher­ge­stellt, dass auch die rich­ti­gen The­men ent­wi­ckelt wer­den (MVP lässt grü­ßen). Die Back­log-Prio­ri­sie­rung sorgt für die kor­rek­te Priorität.

Ein oft ange­trof­fe­nes Pro­blem ist, dass bis dato vie­le Stake­hol­der sich nicht so ger­ne mit den Details und Tie­fen ihrer Wün­sche aus­ein­an­der set­zen wol­len – das ist ja zu viel Arbeit. Aller­dings ist im gro­ßen Gan­zen auch zu berück­sich­ti­gen; dass die­se wert­schaf­fen­de Vor­ar­beit vie­le nach­ge­la­ger­te Prozesse/Themen deut­lich vereinfacht.

Ich sehe es als mei­ne Mis­si­on, die­se Invol­vie­rung zu ver­tie­fen und so den Fokus auf die lang­fris­ti­ge – und natür­lich auch erfolg­rei­che – Wei­ter­ent­wick­lung des Pro­duk­tes zur Mehr­wert­ma­xi­mie­rung zu richten.

Als Pro­duct Owner ist Kom­mu­ni­ka­ti­on nun mal der Schlüs­sel zum Erfolg – der den Unter­schied zwi­schen einem erfolg­rei­chen und erfolg­lo­sen Pro­duk­tes ausmacht,

Sebas­ti­an

Vie­len Dank für dei­nen Ein­blick, Sebas­ti­an. Das klingt so, als hät­test du da eine ganz gute Balan­ce gefun­den. Es ist für bei­de Sei­ten eine Umstel­lung: Für die Stake­hol­der / Anfor­de­rer genau­so wie für die Ent­wick­ler; nie­mand kann ein­fach mehr auf den ande­ren zei­gen und sich dar­auf zurück­zie­hen, dass der erst mal die Arbeit machen soll. Es geht nur mit­ein­an­der und genau dar­um geht es.

Schreibe einen Kommentar