User stories – prioritera, planera och följ upp utvecklingsarbetet

Beslutet att utveckla eller uppdatera ett IT-stöd kan upplevas som både spännande och skrämmande. Många har tyvärr dåliga erfarenheter från projekt som dragit över både tid och budget. I många fall har inte heller projektet skapat den förväntade nyttan. Genom att jobba med agila metoder och User stories blir det lättare att prioritera, planera och följa upp utvecklingsarbetet.

User stories påminner oss om vad vi vill kunna göra

Tänk dig att du ska bygga ett hus. Du har planerat allt i minsta detalj och beställt hem alla varor som nu ligger i en stor hög på gården. Allt finns där för att dra igång bygget. Men det blir väldigt krångligt att hitta i den stora högen av material. Du måste börja med att sortera. På samma sätt måste du sortera de olika byggstenarna innan du drar igång ett it-bygge.

–     Vi har ofta en ganska god bild av vad vi ska bygga om vi håller oss på en lite högre abstraktionsnivå. Till exempel att en kund ska kunna lägga en order eller uppdatera sin kundprofil. Du måste göra dina krav greppbara, säger Peter Junermark, som driver det egna företaget Junermark Didaktik & Design och har lång erfarenhet som utbildare och expert inom verksamhetsanalys och systemutveckling.

Om du vet exakt vad du ska göra och på vilket sätt är traditionella projektmodeller oftast mest lämpliga. När det kommer till utveckling av verksamhetsstödjande system är det ofta tvärtom. Verksamheten har svårt att exakt säga vad deras behov är. Dessutom utvecklas verksamheten hela tiden så det som var korrekta krav vid en tidpunkt behöver inte vara det ett halvår senare.

Ett smart sätt att sortera och prioritera bland alla krav är att använda sig av så kallade User stories, användarkrav. Det är en teknik som gör det möjligt att uttrycka de olika behov som finns hos de som ska använda applikationen.

–    En User story är en ”påminnelse” om något som man vill kunna göra med systemet för att uppnå eller skapa ett värde, men den säger ingenting om detaljerna. Syftet är samla allt som man vill kunna göra i applikationen så att man kan prioritera User stories sinsemellan, förklarar Peter Junermark.

Fokus på det viktiga

User stories ger alltså en bild av vad vi vill att it-lösningen ska göra. De sätter fokus på nyttan utan att krångla in sig i detaljerna. En User story ger svar på de tre frågorna; Vem ska göra, Vad och Till vilken nytta?

–       User stories hjälper dig att sätta fokus på det viktiga, förklarar Peter Junermark.

Vad är en User story?

  •  Är en teknik för att fånga in användarnas krav.
  • Svarar på vem som ska göra vad och till vilken nytta?
  • Sätter fokus på användarrollen och den nytta it-lösningen ska ge.
  • Ger hjälp att sortera användarkraven efter olika teman.
  • Kan användas för att se hur olika användarkrav hänger ihop och hur viktiga de är i förhållande till varandra.
  • Ger ett viktigt underlag för att planera utvecklingsarbetet så att man skapar mest värde först.

Prioritera user stories

Första steget är att dela upp den tänkta applikationen i olika teman. Om du ska utveckla en webbshop så behöver du exempelvis hantera kunder och produkter, ta betalt och ta fram försäljningsstatistik. Dessa områden av funktionalitet kallas teman. Inom varje tema finns User stories. Med en Story map kan man visualisera teman och user stories. I Story mappen framgår också prioriteringar och beroenden mellan User stories.

Nästa steg är att skapa en roadmap för utvecklingsarbetet – i vilken ordning ska utvecklingen ske?

–     Vissa User stories är kanske helt avgörande för att applikationen ska vara användbar, medan man kan vänta med andra. Försäljningsstatistiken i exemplet ovan kanske är bra att ha framöver, men är inte viktigt att ha på plats dag ett. En viktig fråga att ställa sig är vilken är den minsta mängden av User stories som skapar ett värde till användarna. Det bör bli den första versionen av applikationen, förklarar Peter Junermark..

I projektet samlas alla User stories i Produktbackloggen, en prioriterad lista med allt som är kvar att utveckla. Det som finns överst i Produktbackloggen är det som är högst prioriterat, alltså, det som skapar mest värde för verksamheten. För dessa User stories behöver kraven detaljeras. Poängen är att man gör detta lagomt länge innan det är dags att realisera User storyn. På så sätt minimeras risken att förutsättningarna ändras.

–     Du behöver inte alltid ha alla exakta krav klara när du börjar. Fördelen med att jobba med User stories är att du kan anpassa och detaljera efterhand, säger Peter Junermark.

Minns du exemplet i början, med husbygget? Man skulle kunna beskriva i detalj hur allt i huset ska se ut innan man drar igång, från placering av belysning till val av golvlister och tapeter. Men man kan också ha en mer översiktlig plan av hur arbetet ska ske och hur rummen ska se ut. Att utveckla it-lösningen med User stories som utgångspunkt är som att bygga ett hus rum för rum.

Den lösning du trodde var den bästa från början kanske inte riktigt fungerar som du tänkt dig. Genom att bygga systemet bit för bit finns det utrymme för att anpassa och utveckla arbetet utan att låsa fast sig i en viss lösning, utan att specifikationer och beställningar måste ändras.

–     Du kanske upptäcker att en User story inte var så viktig som du trodde från början, eller att den var mycket större än du trodde och behöver delas upp i fler.

Genom att hålla fokus på användarnyttan blir det lättare att utveckla smarta lösningar. På så vis kan man hitta en teknisk lösning som fungerar samtidigt som användaren hela tiden är i fokus. En viktig poäng med att arbeta med User stories är att verksamheten blir involverad och engagerad i arbetet. Många gånger är det endast verksamheten som kan avgöra vad som är viktigast och vilka User stories som bör prioriteras i den lösning de vill ta fram.

–     En User story är egentligen bara en påminnelselapp. Men den hjälper dig att fokusera på användarnyttan och att sortera, prioritera, se samband och göra saker i rätt ordning, säger Peter Junermark.

Anna Nyström

Anna Nyström

Anna är journalist och skriver för Astrakan om kravarbete, systemutveckling och ledarskap.