De kommunikative aspekter omkring fremdriften af udviklingen spiller nemlig en stor rolle og vil ofte være udslagsgivende for den udviklede løsnings endelige succes.

Som ansvarlig for leveringen af en lang række mobil- og webapplikationer til både det private erhvervsliv og til offentlige institutioner, har vi oplevet store fordele ved at styre udviklingen af IT-løsninger med ovenstående in mente. User stories har i den forbindelse været et værdifuldt redskab.

User stories giver et fælles sprog

User stories udspringer af erkendelsen af, at dialog mellem alle interessenter er nødvendig for at kunne opnå det bedst mulige produkt. Med sin simple struktur (se eksemplet i den blå ramme)etablerer user stories et fælles sprog, som kan anvendes af alle involverede parter. Hele kæden fra den tungeste backend-udvikler til den mindst IT-orienterede kunde kan forstå og bidrage til user stories. Det styrker koordineringsarbejdet markant.

User stories er et udbredt redskab i mange virksomheder, men implementeringen kan være meget forskellig. Dette er i grunden fuldstændig i tråd med, at “processer og værktøjer” anses for vigtige, men aldrig må overskygge ”individer og samarbejde”. Men det medfører omvendt også en risiko for, at potentialet ved user stories ikke udnyttes fuldt ud.

Eksempelvis bør du være opmærksom på disse fire forbehold, når du bruger user stories:

1. User stories er ikke one-size-fits-all 

Inden vi dykker ned i mere specifikke forbehold, vil jeg starte med at notere, at user stories ikke er nogen mirakelkur. Selvom det skaber værdi at bestræbe sig på at lade sin backlog bestå af user stories i så høj grad som overhovedet muligt, vil der altid være arbejde, som ikke giver mening at formulere i dette format. Det skaber ingen værdi at formulere stories såsom “Som en udvikler skal jeg migrere data fra vores gamle CRM”. User stories skal have fokus på brugerne af systemet.

Omvendt skal man passe på med at fravælge user stories eksempelvis fordi et teammedlem foretrækker en anden måde at beskrive arbejde på. Det leder mig videre til næste forbehold.

2. User stories bør ikke være en oversættelse 

De fleste involverede parter i udviklingen af software-løsninger vil fra tidligere have været vant til at arbejde med andre måder at beskrive denne type af udviklingsprocesser på. Use cases, flowcharts og meget andet er eksempler på værktøjer som folk har med sig i bagagen. Disse kan uden tvivl bidrage med vigtige nuancer til de enkelte user stories.

Det er dog vigtigt, at der ikke opstår parallelspor, hvor forskellige parter benytter deres egne måder at beskrive processen på, hvorefter det overlades til eksempelvis en udviklingsleder at sikre alignment. I mit arbejde, bruger jeg i stedet energi på, at alle interessenter forstår og bidrager til de user stories, som findes i backloggen, og mindsker dermed risikoen for, at vigtige detaljer mistes i oversættelsen.

3. User stories må ikke overlappe flere sprints

Hvis du (som de fleste agile teams) anvender Scrum som primær metodologi, bør hver iteration bidrage med ny afrundet funktionalitet til produktet. Derudover skal user stories (som vi tidligere har været inde på) være helhedsorienterede og formuleres med tanke på slutbrugeren og ikke eksempelvis hvilke teknologier, der skal anvendes for at imødekomme dem (læs: hver user story bør dække full stack).

Disse to forhold er vigtige at gøre opmærksomme på og betyder, at user stories altid skal være af en størrelse, hvor de kan afsluttes inden for den sprint, de først lægges ind i. Er en user story for kompleks til, at dette kan lade sig gøre, vil vi i langt størstedelen af tilfældene anbefale at bryde den ned til mindre user stories, som så hver især kan indgå i forskellige sprints (såfremt de i sig selv bidrager med nye muligheder for slutbrugerne).

4. User stories danner ikke en kravspecifikation

Endeligt er det vigtigt konstant at minde alle interessenter om, at det primære formål med user stories ikke er at formulere specifikke krav, som efterfølgende skal følges slavisk. User stories vil ofte indeholde færre konkrete beskrivelser end hvad der eksempelvis ses i mere rigide formater såsom use cases. Dette handler ikke om manglende vilje til at dokumentere det forestående arbejde, men derimod om erkendelsen af, at selv den mest detaljerede beskrivelse vil være både mangelfuld og åben for fortolkning.

I stedet sigter vi altid efter at formulere user stories så de er tilstrækkelige (i ordets egentlige forstand) og den overskydende tid bruger vi på at facilitere direkte kommunikation mellem de relevante parter i takt med, at produktet tager form.

User stories er et redskab til dialog og bør derfor bruges som en måde dels at sikre en fælles forståelse for det produkt som udvikles og dels give plads til, at alle (såvel kunde som leverandør) bliver klogere i løbet af udviklingsprocessen.

Nedenfor kan du se eksempler på user stories omsat til funktionalitet på demensvenmatch.dk

Hos twoday betragter vi hvert projekts backlog som en levende organisme i konstant forandring. User stories ændrer løbende form: Nogle præciseres eller ændrer helt formål, andre fjernes og nye kommer til. Samtidig sker der en løbende prioritering af backloggen med det formål at sikre, at udviklingsarbejdet altid har det rette fokus.

Prioriteringen foretager vi sammen med kunden ud fra en samlet vurdering af den værdi, som kunden opnår ved den enkelte user story, sammenholdt med det forventede tidsforbrug og en generel risikovurdering (er denne user story klart nok beskrevet? er der eksterne afhængigheder, der skal afklares først? etc.).

Helt konkret handler det altså om at vi hos twoday bestræber os på altid at arbejde på lige netop dét, som bidrager med størst relativ værdi for kunden. Ved at anvende user stories under den agile udvikling af IT-løsningen sikrer vi, at samarbejdet foregår med alle interessenters involvering via et fælles sprog. Dermed sker prioriteringen på et så velinformeret et grundlag som muligt.

PS. De bedste 52 minutter du kan bruge i dag er at se Mike Cohns præsentation fra NDC 2012 om user stories her.