Om formater på user stories, og så en pointe om at det er godt og nyttigt at kende redskaberne i den agile værktøjskasse, men at vi skal huske formålet med dem — ellers bliver det ligegyldigt.
Jeg hørte for nyligt om et team, hvor nogle insisterede på, at alt planlagt arbejde skulle skrives "som user stories".
Først troede jeg, at pointen var, at de gerne ville koncentrere alle kræfter om opgaver som brugerne kan mærke, i stedet for at bruge tid på at bygge infrastruktur og andre opgaver som kun kan mærkes indirekte. Det er nemlig også et godt emne — hvordan vi deler vores tid mellem "brugerhistorier" og "tek-historier" — og det vender jeg sikkert tilbage til en anden gang. Men nu var det ikke det, de mente; i stedet ville de gerne sikre, at alle opgaver blev formuleret efter samme skabelon. Det vil jeg her gerne bruge som et eksempel på, at vores "agile værktøjer" ikke er så meget værd, hvis vi ikke husker formålet med dem.
Case: Formater for user stories
I den konkrete situation handlede det altså om, hvordan opgaverne skal formuleres. De ville gerne have, at alle user stories skulle skrives på formen
As a <role> I can <capability>, so that <receive benefit>"[^Mere eller mindre kendt som the Connextra template, hvis du vil vide mere.]
Det er ikke nogen dårligt skabelon til en user story; da jeg selv blev opmærksom på den (små 10 år inde i min egen agile løbebane), begyndte jeg også at bruge den og anbefale den. Den gør nemlig to ting tydeligt, som jeg syntes mit daværende kæmpeprojekt havde godt af at blive mindet om:
- en user story skal være kort
- formålet med user story'en er vigtigt
Indtil da havde jeg mere kørt efter det helt klassiske mantra: "a user story is a promise of a conversation", og de fleste user stories vi arbejdede på i mine små, dynamiske teams i start-ups, bestod som regel af en overskrift på et kartotekskort på væggen — suppleret af en god snak om hvad historien gik ud på, hvad formålet var, og hvordan det mon bedst kunne opnås.
På mit meget store projekt var vi en sammenbragt skare med forskellig bagage, og nogle var meget opsatte på at en opgave skulle være selvforklarende og indeholde alle nødvendige detaljer (når man nu har lært at skrive kravspecifikationer må det også være pokkers ærgerligt ikke at få lov...). I den kontekst blev jeg hurtigt en fan, da "As a..." blev foreslået som fælles skabelon, og den tjente os godt.
Siden er jeg stødt på formatet mange gange; mange har lært at bruge det på kurser i agil softwareudvikling, og det bliver vist i nogle kredse set som "den rigtige måde at formulere user stories på". Det skal jeg ikke gøre mig til dommer over; jeg synes som sagt det er fint — men jeg vil gerne advare mod at tro, at bare man bruger det format, så er det en god user story.
Hvad kan der da være galt?
Jo, man kan jo proppe nærmest hvad som helst ind på det format. "Som din chef vil jeg have feature X fordi jeg synes det er en god idé". Det hjælper os ikke, at formatet tilsyneladende overholdes.
Eller "Som databasen skal jeg backes op, så jeg kan genskabes efter et datatab" — jo tak, godt og nyttigt, men det er jo ikke en user story: den handler ikke om brugernes behov. Det er en god og væsentlig opgave, men den vinder jo ikke meget ved at databasen bliver personliggjort. Det ligner et forsøg på at smugle en tek-historie ind som en brugerhistorie, og vi lader os ikke narre.
Man kan også se fejl rapporteret i dette format: "Som bruger skal jeg have svaret OK i stedet for 'internal server error' når jeg indberetter moms for Q4, så jeg kan indberrette min moms". Hvis vi skal rette den fejl vil vi nok hellere have mere konkrete oplysinger om hvordan fejlen kan genskabes end glæde os over, hvor "fint" formatet blev fulgt.
Hvad er ideen med formatet?
Der, hvor jeg synes, at formatet virkelig gør nytte, er når udfyldelsen af "so that..."-delen minder os om, at vi skal kende formålet med opgaven. "Som bogholder skal jeg kunne se en liste over udestående betalinger, så jeg kan følge op med de kunder, der ikke har betalt til tiden". Den sidste bisætning gør det klart, hvad listen over udestående betalinger skal bruges til, og kan hjælpe med at udforme funktionaliteten. Så er det nok vigtigt, at man kan se hvornår betalingen forfaldt, om samme kunde har andre udestående betalinger, og hvor store beløb, der er tale om — og at man hurtigt kan finde kundens kontaktoplysninger. Det kunne også være klaret med en snak mellem udvikler og bogholderi, og den anbefaler jeg bestemt også, at man tager — men det er en god start at gøre sig klart hvem brugeren er, og hvad formålet er.
Afsluttende om formatet på user stories
Så ja, brug gerne formatet, hvis det hjælper jer til at huske at få det vigtige med — the why, not the how.
Det kan også bruges som tjekliste — har jeg svaret på hvem, det konkrete behov, og det egentlige behov? Hvis der er svaret på det, så er det mig lige meget, om formatet er overholdt og der startes med "As a...".
Hvis formatet "gør modstand" og den opgave, der skal beskrives, ikke rigtigt passer ind i formatet, så overvej om det er formatet, der har ret, eller opgaven er god nok, men bare ikke passer i formatet. Hvis du tænker "Jeg ved da ikke, hvorfor de gerne vil det", så er det nok værd at finde svaret, før opgaven sættes i gang. Hvis der ikke rigtigt er en bruger, så er det måske fordi, det er en (god og vigtig?) tek-historie, og så skal den formuleres og vurderes ud fra nogle andre kriterier.
Hvis man er opmærksom på, hvorfor det format er så populært, hvilket behov, formatet prøver at opfylde, så er det også mere sandsynligt, at man bruger (eller vælger ikke at bruge) formatet på en god måde; på en måde, hvor man opnår det, man gerne vil: at man husker brugeren, og at man husker at få beskrevet formålet.
Mere generelt: husk hvorfor
Det samme gør sig gældende for snart sagt alle værktøjerne i den agile værktøjskasse: hvis man ikke husker på (eller forstår) formålet med dem, så bliver de let til en tomme øvelser, spild af tid, og kontraproduktive.
Det gælder blandt andet
- daily scrum
- retrospectives
- TDD
- PO-rollen
- par-programmering
- definition of done
- ...
Alle sammen gode og nyttige hvis de bruges rigtigt. Hvis man derimod ikke overvejer formålet og bare implementerer dem alle sammen (dårligt), fordi "det skal man", så drukner man barnet i badevandet.[^Beklager den mishandlede metafor.]
Det er mere agilt at reflektere over dem og vælge til og fra, så man bruger dem, man får udbytte af, end blindt at "krydse dem alle sammen af".
