User Stories

Ideen med Scrum er at man i hvert sprint gør noget helt færdig, hvilket for mange betyder at de er nød til at tænke og opdele store opgaver anderledes. Da man nu bliver udfordret på at man efter hvert sprint har noget nyt der potientielt kunne bliver lagt i produktion med det samme.

Der er ofte en tendens til at man angriber ting i lag (tier) - dvs. man fx siger at der er præsentation, forretningslogik og persistering, og så starter man fx med at lave persistering og derefter forretningslogikken og til sidst præsentationen. Denne model dur ikke opgaven er så stor at den kommer til at strække sig hen over flere sprint og man gerne vil arbejde efter Scrum metoden. For man har så ikke noget nyt der potientielt vil kunne ligges i produktion efter hvert sprint.

Her skal man istedet tænke vertitalt – dvs. dele opgaven i mindre opgaver der hver indeholder lidt i alle lag. Det kunne fx være muligheden for at oprette en bruger. Her er det både noget præsentation hvor man kan indtaste nogle oplysninger, der er noget forretningslogik der skal validere oplysningerne og til sidst skal oplysningerne persisteres. Andre opgaver kunne så være mulighed for at redigere eller slette brugeren. Det er når man begynder at tænke sine opgaver på denne måde at User Stories kommer ind i billedet.

En User Story minder lidt om det mange kender som Use Case, men hvor Use Case er meget fokuseret på hvad man kan, forkusere User Story mere på hvad man vil og motivationen. Jeg vil en anden gang skrive lidt mere om forskellene mellem User Stories og Use Cases.

User Stories beskriver hvem brugeren er, hvad han gerne vil opnå og hvad der motivere ham. Derudover kan der til hver User Story være tilknyttet en række noter, som kan uddybe User Story’en med fx tekniske krav, begrænsninger og forudsætninger. Der er ingen regler for hvordan en User Story skal skrives, det er blot vigtigt at den indeholder de tre vigtige informationer om hvem brugeren er, hvad han vil opnå og hvad der motivere ham. Og så skal en User Story incl. noter gerne indeholde nok information til at enhver (med indsigt i domænet) kan danne sig et billede at hvordan det kan løses.

Som nybegynder i at skrive sådanne User Stories kan det være svært at huske at få alle tre ting med, derfor er denne lille skabelon utrolig brugbar “Som en ___, vil jeg gerne ___, for at ___.“. Hvis man benytter denne skabelon er man hjulpet på vej til at få alle tre ting med.

Første del af skabelonen “Som en ___,” fortæller noget om hvem brugeren er. Det kunne fx være “Som en togrejsende,” eller måske endda “Som en togpendler,“, forskellen på disse to kunne give noget information om hvor ofte brugeren rejser med toget. Det kunne måske endda være “Som en togrejsende, der rejser med tog mere end 5 gange om ugen,“. Det gælder her altså om at være på præcis omkring hvem brugeren er, men stadig holde det på et niveau så det ikke bliver unødig information.

Anden del af skabelonen “vil jeg gerne ___,” fortæller noget om hvad man gerne vil opnå. Det kunne fx være “vil jeg gerne kunne købe min billet hjemmefra“, her står det lidt åbent om man fx vil gøre det med brev, telefon eller via Internet. Så den kunne også skrives som “vil jeg gerne kunne købe min billet via Internet“, men igen kan man sige det er lidt åbent om det fx er via e-mail eller et lille program man skal installere. Det svære med denne del af skabelonen er at få skrevet noget der er så præcist som muligt uden man kommer for meget ind på hvordan det skal løses. I dette tilfælde vil jeg mene at det ville være acceptabelt at skrive noget med “vil jeg gerne kunne bestille min billet via togrejseudbyderens hjemmeside,“. Men igen er det en hårdfin grænse, som man nok selv skal finde det passende niveau til.

Tredje del af skabelonen “for at ___.” fortæller noget om hvad motivationen er. Det kunne fx være “for at slippe for lange køer ved skranke eller automat på stationen.” eller “for at kunne købe billetten når det passer mig og ikke skulle tænke på hvornår billetsalg har åben.“. Det man ikke skal med den tredje del er at gentage det man har skrevet i den anden del. I dette tilfælde vil det ikke give meget mening at skrive “for at kunne købe billetter via togrejseudbyderens hjemmeside“, en sådan sætning er blot et udtryk for at man lige så godt kunne udelade den tredje del for den giver ikke nogen ny information, men jeg nægter at tror at motivationen er den samme som det man gerne vil gøre. Hvis man gerne vil spise en is, er det jo ikke fordi man gerne vil spise en is, men fordi man har lyst til en is.

Hvis vi nu sammensætter nogle af eksemplerne fra de tre dele så kunne det fx blive til “Som en togrejsende, der rejser med tog mere end 5 gange om ugen, vil jeg gerne kunne bestille min billet via togrejseudbyderens hjemmeside, for at slippe for lange køer ved skranke eller automat på stationen.“. Når man læser dette kan man selfølgelig se at man gerne skal kunne bestille en billet vi togudbyderens hjemmeside, men man kan også se at det åbanbart ikke er så vigtigt hvis man rejser mindre en 5 gange om ugen og at processen nok ikke skal resultere i at man skal hente billetten i en automat eller ved en skranke. Det er alt sammen nyttig information når man skal udtænke hvordan opgaven løses med det bedste resultat.

Jeg nævnte tidligere at der til en User Story kunne være tilknyttet en række noter, der er ingen regler for hvad disse noter indeholde af information, men lad være med at skrive noget bare for at skrive noget. Hold dig til at skrive noget der beriger User Story’en med noget. I vores tilfælde kan det være at det skal virke via browser på PC, men også kunne benyttes via browser på mobiltelefon. En note kan også være noget om noget den ikke skal kunne eller noget løsningen ikke må benytte sig af. Det kunne være noget med at der fx ikke må benyttes en Flash eller Java Applet.

Min tommelfingerregel til hvor lang en User Story skal være og hvor lang en note skal være, er at forsøge at holde hver af de tre dele af skabelonen til at være one-liners, og det samme gælde noterne. Det kan nogle gange være svært, men min erfaring er at bliver det mere end one-liners begynder man ofte at skrive en masse unødig information, og det er både forfatter og læser bedre tjent uden. Vær så præcis som muligt i dine formuleringer, uden du kommer til at udelade noget af det vigtige eller bruger oceaner af tid på at finde den rette formulering, det skulle gerne være let og hurtigt at skrive sådan en User Story, det er jo blot at nedfælde dine tanker om hvad du gerne vil.