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 Beck, Ward 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.