Skillnaden mellan user stories och krav

En av de starkaste associationerna som många gör är den mellan krav och acceptanstest. Idén härstammar ursprungligen från den gamla V-modellen som innebär att man i en kravfas definierar produktkraven och i en accpetanstestfas verifierar och validerar produkten med kraven som facit. Som teoretisk idé fungerar det bra eftersom det är logiskt och enkelt att förstå. I praktiken är det en fullständig katastrof. Även hos dem som arbetar i agila projekt verkar dock det här tankesättet vara djupt rotad. Konsekvensen blir att man betraktar "user stories" som krav där man till varje pris ska "kontraktera" och avkräva beställaren en komplett systembild från början. Man är angelägen om att få med alla detaljer, att allt ska vara genomtänkt och rätt från början. Men det är alls inte tanken med user stories.

  • User stories är inte krav!
  • User stories är inte kontrakt!
  • User stories är inte en komplett specifikation! 

Ron Jeffries, en av grundarna till Extreme Programming) uttryckte det elegant: "A User Story is a promise of a future conversation".

Själv betraktar jag user stories som projektets "att göra"-lista. Det är precis på samma sätt som när man planerar en semestervecka. Man skriver ner vad man vill göra och vad man vill se, knappast hur man i detalj tar sig till varje plats, vilken buss man ska ta eller på vilken hållplats man hoppar av, inte att man ska ska fälla upp paraplyet om det regnar och inte vad man ska ha till lunch dag 2.

Hur vet man då vad man ska implementera med utgångspunkt från en sådan vag beskrivning? Genom konversation (kom ihåg Ron Jeffries ord) och kollaboration mejslar teamet steg för steg fram en fungerande och användbar produkt. Detaljerna konvergerar successivt och resulterar i acceptanskriterier som verifieras och valideras kontinuerligt genom hela utvecklingsprojektet.

Om författaren
Mats Wessberg är VD och medgrundare av Inceptive. Han har verkat i IT-branschen sedan 1995 och mestadels som konsult. Hans huvudsakliga expertis är inom Quality Management och utvecklingsmetodik.