Agil kravhantering

Häromdagen hamnade jag i en diskussion om på vilken nivå man bör skriva user stories och jag konstaterade att det här är ett område där det finns olika uppfattningar. Till att börja med, låt oss vara överens om en viktig sak - en user story är inte den agila versionen av ett detaljerat krav. Det är gnistan som sätter i gång den kedjereaktion av aktiviteter som så småningom resulterar i en ny fungerade funktionalitet. En av dessa aktiviteter är att upptäcka och kommunicera de ännu okända detaljerna. Man brukar skriva en user story på en form liknande denna:

"Som en <roll> vill jag <ett mål> så att <motiv>"

T.ex.

"Som en forummedlem vill jag logga in så att jag kan skriva inlägg i mitt namn"

I det här exemplet är det klart att man vill ha någon form av inloggningsfunktion, men detaljerna är utelämnade. Är en så här enkel story tillräcklig att ta fram den kompletta inloggningfunktionaliteten? Nej - om man tror att tänkbara scenarier täcks av en mening. Ja - om man betraktar meningen som startpunkten för att upptäcka dem.

Vilka är detaljerna som kan behöva uptäckas? Här är några exempel:

  • Hur ska användarnamn och lösenord se ut?
  • Hur många gånger ska man kunna skriva fel lösenord innan man vägras nya försök?
  • Ska ett nytt lösenord genereras om användaren glömt det?
  • Eller ska det skickas till den registrerade epostadressen?
  • Ska man tvingas byta lösenord med jämna mellanrum?

Man kan hävda att om det redan från början är "känt" att man bara ska få tre chanser att ange sitt lösenord kan man ju lika gärna skriva det. Men stanna upp och betrakta punktlistan. Vad skiljer den från gamla tiders punktlistbaserade kravdokument? Ingenting. Ett problem med en sådan detaljeringsgrad är att den begränsar teamets frihetsgrad att ta fram den bästa lösningen. Vad är det som säger att tre chanser är "rätt" krav. En user story ska aldrig tolkas i frånvaro av en produktägare, dvs det får aldrig bli en kravlista, det måste vara grunden för en konversation mellan team och produktägare.

Men kan man inte ha en konversation även om de i förväg skrivna detaljerna? De behöver ju inte vara skrivna i sten. Förvisso sant, men betänk då hur ett projekt fungerar i praktiken. I regel har man massor att göra, långa rader av user stories att planera, design att göra, kod att skriva och möten att gå på. Om man har en löst skriven story så tvingas man diskutera den. Men detaljer ligger mycket närmare till hands att betrakta som färdiga och just skrivna i sten.

Gör i stället som en konstnär som målar en tavla. Börja med konturerna och fyll i detaljerna efter hand. Gör varje story så grund som möjligt och lämna så mycket som möjligt till konversationen. Det må vara mindre bekvämt än att få detaljerna serverade, men resultatet kan bli mycket bättre.

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.