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 wur­de.

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 Sto­ry.  

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ön­nen.  

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 schrei­ben.

A user sto­ry is a pro­mi­se for a con­ver­sa­ti­on.

Alis­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.

Du willst keinen Artikel mehr verpassen?

Mit mei­nem News­let­ter bekommst du ein­mal wöchent­lich die neu­es­ten Arti­kel direkt in dei­nen Ein­gangs­korb.

6 Kommentare

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

Hal­lo Mar­kus,
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 Manage­ment-Kon­trol­le.
Viel­leicht ste­he ich aber mit die­ser Beob­ach­tung allei­ne da.
Vie­len Dank für den Bei­trag.

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 arbei­ten.

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

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 Prio­ri­tät.

Ein oft ange­trof­fe­nes Pro­blem ist, dass bis dato vie­le Sta­ke­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 ver­ein­facht.

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 rich­ten.

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 aus­macht,

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 Sta­ke­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