User stories er et koncept der på papiret lyder godt, men kan være rigtig svært at arbejde med i dagligdagen. Der er ikke noget odiøst over konceptet, men ved korrekt anvendelse giver det en ramme til at beskrive hvem der er slutmodtager af et ønske, hvilken handling der ønskes samt en begrundelse for ønsket. Tilsammen skaber det en kontekst der gør det lettere at forstå problemstillingen for development team således at de kan arbejde effektivt.

For at skabe lys over situationen vil jeg her prøve at beskrive en situation fra den virkelige verden og formatere ønsket som user stories.

Baggrund

Dette virkelige eksempel tager afsæt i et community site der dagligt bliver anvendt af tusindvis af brugere i primært Danmark og Norge. Sitet har en lang række features her i blandt nyheder, medlemsarkiv, mødehåndtering (inkl. tilmelding og referater) og login. Organisatorisk er sitet bygget op omkring lokale klubber som har et regionalt og nationalt tilhørsforhold.

Sitets arkitektur er forholdsvis klassisk og bygger på en modular konstruktion med front-end, logik og infrastruktur.

Den gode ide

Via sitets ideforum er følgende input modtaget og prioriteret til implementering:
“Referater fra møder skal udelukkende distribueres i PDF format.”

En ganske fornuftigt ide, som også er overkommelig at løse. I dag er det muligt at uploade referater i HTML, PDF, Word, Powerpoint og mange andre formater. Systemet udsender referater til mødedeltagere via et link til community-sitet.

Straight-to-code nedbrydning

Én af udviklerne fra development-teamet er bedt om at give et estimat og en mulig løsning på opgaven. For at konkretisere estimatet er følgende nedbrydning foretaget:

• Referater fra møder skal udelukkende distribueres i PDF format
• Opdater mail funktion til at distribuere PDF
• Opdater front-end til kun at tillade PDF referater

Umiddelbart en ganske fornuftig nedbrydning – dog udelukkende med fokus på “hvad” der skal laves. Det kan være rigtig godt at arbejde på denne måde hvis man arbejdet i et lille team hvor alle har dyb kendskab til domæne og brugere. Udfordringen med nedbrydningen er dog at der er mange løse ender som bør afklares inden der sprintes.

Hvem, hvorfor og hvad

Arbejder man i et større team – eller måske endda med offshoring/outsourcing – kan det bidrage gevaldigt til forståelse af problemet hvis man spørger – og svarer – på spørgsmål om hvem der er modtager af ændringen, hvorfor de ønsker det og hvad der forventes at kunne opnåes.

Det giver anledning til følgende overordnede user stories:

• Som sekretær for min lokale klub vil jeg gerne uploade PDF referater således at referater altid læses i mit tænkte layout og design
• Som læser af referater ønsker jeg kun at modtager referater som PDF således at jeg har en ensformet måde at læse referater på

Opsummering

Der er mange fordele ved ovenstående notation, som nævnt tidligere, i tillæg til kontekst omkring opgaven, så giver det også mulighed for at prioritere opgaverne. Det må eksempelvis forventes at der er flere modtagere af mødereferater end der er sekretærer der skriver dem. Med afsæt i denne antagelse vil det være oplagt at løse den user story der er målrettet læsere før den der målrettet sekretærer.

Jeg har ofte set at user stories finder anvendelse i teams der arbejder eksplorativt sammen med brugere. Her kan det lette kommunikationen hvis man forsøger at beskrive ønsker i brugerperspektiv fremfor at fokusere på den tekniske vinkel.

Når det er sagt, så er jeg ikke fanatisk tilhænger af user stories. For mig er det vigtigste egentlig de tre grundpiller: hvem, hvad og hvorfor. Hvis man er i stand til at fange dem i andre typer krav, så kan det være ligeså godt.

Se de øvrige indlæg i “hands-on” serien:

• http://qed.dk/rasmus-kaae/tag/hands-on/