I Agila utvecklingsprocessen använder vi oss av ”user stories”.
En ”user story” är en beskrivning av ett visst behov eller krav. En story är skriven på en lapp och är uppbyggd på följande sätt:
"Som en <roll>, vill jag kunna <mål/funktion> så att <nytta>"
I ett projekt finns det många storys och jag rekommenderar att varje story inte är för stor, d.v.s. att den inte tar lång utvecklingstid. Det är mer motiverande att ha mindre storys så att progressen går snabbare framåt.
Här nedan har jag beskrivit processen som en ”user story” går igenom i en utvecklingsprocess.
En User Story är född!
Det är vanligt att vi i början av ett projekt sätter oss ner tillsammans med produktägaren och brainstormar fram så mycket stories som vi kan komma på. Vi tänker högt och lågt och går igenom processen som systemet ska stödja.
Det är garanterat att inte alla storys kommer med från början. Man kommer på vägen alltid att upptäcka storys som vi inte tänkte på. Det här är mycket vanligt och jag skulle faktiskt bli orolig om inga ändringar eller nya storys kom fram under projektens gång.
Prioritering
När vi tror vi har skrivit tillräckligt med user story-lappar, då måste de prioriteras. För varje story ställer vi oss frågan om den uppfyller våra verksamhetsmål och hur viktig den är. Metoden jag brukar använda heter
"User Story Mapping" och är ett väldigt bra sätt att prioritera storys och se
dem i sammanhang med varandra. Vi börjar arbeta med de storys som är
högst prioriterade och som ger mest nytta.
Research
Nu när vi vet att vår story är högst prioriterad och näst på tur, ställer vi oss ännu fler frågor kring storyn, bland annat: (inte en tömmande lista)
- Vad innebär storyn?
- När används den, hur ofta och av vilka användare?
- Har den något att göra med andra processer, system eller användargrupper?
- Vilka tekniska möjligheter har vi för att lösa den?
- Kommer vi att använda oss av ny eller befintlig teknik?
- Hur stor är storyn, är den komplex att utveckla, kommer det att ta lång tid?
- Måste vi bryta ner den till mindre storys?
Research görs i nära samarbete med produktägare, relevanta användare och andra specialister, systemarkitekten och utvecklare.
Skissande
Man kan såklart börja skissandet när som helst, men när man tycker man har fått ihop tillräckligt med information kan man börja skissa hur den storyn ska fungera, hur den ska se ut och var den ska
få plats i flödet.
Skisserna är inte bara tänkta för att visa hur storyn ska fungera i systemet
utan också ett väldigt bra sätt att få fram information och feedback från användare. Skisserna itereras och ändras ofta. Människor har så mycket
lättare att kommentera på en skiss än på en lång beskrivning i text. En skiss säger mer en 1000 ord!
Genomgång och godkännande från produktägare
Resultat från research samt skisserna bildar en beskrivning som används
vidare i utvecklingsprocessen.
Innan utvecklarna börjar jobba med storyn stämmer vi av en sista gång med produktägaren. Vi vill vara säkra att vi har förstått rätt och att beskrivningen stödjer verksamhetsmålet samt möter användarnas förväntningar.
Genomgång med utvecklingsteam
När produktägaren har godkänt beskrivningen och skisserna av storyn är dags att göra en genomgång med relevanta teammedlemmar. Då sätter vi oss ner; UX-människor, utvecklare som kommer att utveckla storyn och testare som kommer testa storyn.
Vi tittar på skisserna tillsammans och läser igenom beskrivningen. Vårt mål med genomgången är att uppnå delad kunskap om storyn inom teamet samt att lyssna på förslag på förenklingar eller förbättringar från teammedlemmar.
Påbörjad utveckling
Efter genomgången med utvecklingsteamet är möjligt att bryta ner storyn i lite mindre tasks och börja utveckla den. Med jämna mellanrum demar vi för varandra samt för produktägaren.
Under storyns utveckling är UX-människan alltid tillgänglig för att svara på frågor som dyker upp.
Acceptanstest
När utvecklingsteamet är överens om att en story är klar, då visas utvecklade storyn för produktägaren. Den/de får säga till om något saknas fortfarande eller något har uppfattas fel. Förhoppningsvis har vi redan fångat det i storyns alla tidigare moment.
Regelbundna användartester
Användartester är mycket viktiga och endast användartester kan berätta om en story kommer att fungera som vi tänkte. Bäst är att bestämma regelbundna användartester under hela utvecklingsprocessen, det kommer alltid att vara något som går att testa. Användare behöver inte alltid testa färdig funktion, det går väldigt bra att testa idéer, skisser och tänkta flöden med användare.
