User stories skiftar fokus från dokumentation till diskussion i ditt projekt

3 april, 2018

Att ställa krav på ett nytt system är inte lätt – investeringen ska räknas hem genom effekterna av införandet samtidigt som funktionaliteten ska motsvara förväntningarna. User Stories är en utbredd metod för att beskriva kraven och förväntningarna som finns på ett system. Detta inlägg ska ge dig som på något sätt är involverad kring kravställning i ett projekt en grundläggande bild av vad en User Story är och varför de är bra.

Att löpande diskutera, prioritera och förändra funktionaliteten är desto viktigare. Jag skulle vilja hävda att detta mindset är en nyckel till ett lyckat projekt, och syftet med User Stories är att främja detta.

Det traditionella sättet att hantera krav och förväntningar var, och är i många fall fortfarande, att skriva en kravspecifikation. Denna listar på ett strukturerat sätt den funktionalitet som systemet ska ha på så detaljerad nivå som möjligt. Ett krav på en säljstödsapplikation skulle exempelvis kunna vara “Det ska gå att ändra status på en offert”, med tillhörande information om bland annat vilka statusar som ska vara valbara. I grunden är det inget fel med detta. Däremot finns ett antal svårigheter.  

  • För det första så är det tidskrävande att formulera kraven: Ofta är många personer inblandade samtidigt som allting ska samordnas i ett strukturerat dokument. Eftersom kraven ska vara tydliga krävs att tid läggs på att detaljera dessa.
  • Kravstrukturen uppmuntrar inte till diskussion, prioritering och förändring. En detaljerad kravspecifikation upplevs ofta som låst och färdig för utveckling. Prioritering och förändring försvåras också av att kraven ofta saknar svar på frågorna “vem?” och “varför?”.

Risken är att mycket tid läggs på att producera text vars verkningsgrad riskerar att bli låg, snarare än meningsfullt resultat i form av användbar programvara.

Vad är då User Stories?

En User Story är ett annat sätt att formulera önskemål om funktionalitet för ett system. Framvuxet i agila metoder där kraven förutsätts vara föränderliga adresserar man problemen med den traditionella kravspecifikationen.

User Stories kompletterar det traditionella kravets “vad?” med “vem?” och “varför?”. Tanken med User Stories är att de ska vara kortfattade och kunna skrivas av såväl beställare som användare och utvecklare.

Det finns lite olika sätt att strukturera en User Story på. Ett gemensamt är att de utgår från en användares perspektiv. Exempelvis: “Som säljare kan jag ändra status på en offert så att jag vet vilket skede den är i“. Tidigt i ett projekt är en User Story ofta mindre detaljerad, kanske snarare: “Som säljare kan jag hantera mina offerter”, och kallas då för en Epic. Efterhand bryts dessa ner och blir mer detaljerade. I de flesta fall bör de även kompletteras med information kring hur implementationen ska ske.

En User Story går snabbt att skriva och uppmuntrar till diskussion. Den korta formuleringen till och med förutsätter dialog om vad som avses med den. Att dialog behövs är allt som oftast sant också för den mest välformulerade av kravspecifikationer. Med User Stories blir kravarbetet mer transparent och det gör förväntningarna mer balanserade. Eftersom man också vet för vem funktionen ska finnas och varför så underlättas eventuell framtida förändring och prioritering.

Exakt hur vi formulerar den funktionalitet ett system ska ha kan tyckas vara en mindre viktig detalj – och det är det kanske också. Att löpande diskutera, prioritera och förändra funktionaliteten är desto viktigare. Jag skulle vilja hävda att detta mindset är en nyckel till ett lyckat projekt, och syftet med User Stories är att främja detta.


Digitalisering

Dela

Share on LinkedInTweet about this on TwitterShare on FacebookShare on Google+