Blogg

Men det här var ju ingen user story?!

  • 16 oktober 2015
  • 2

Vad är det för fel med en story som börjar på följande vis: "As a user I want to logon so that I can.."?  

Artikelverktyg:

Smidiga system

För några dagar sedan snubblade jag över en tjänst som inte kräver någon inloggning alls utan unika adresser skapas för att hantera åtkomst till vissa saker. Det finns många tjänster och applikationer där en liknande lösning räcker mer en väl. De som byggde just den här tjänsten hade INTE heller en user story som börjar med "As a user I want to register in order to login" eller "As a user I want to login so that I can access.." när de byggde sitt system.

En user story

Om man börjar från början så är storyn ovan förmodligen lögn. Jag har många gånger hjälpt kunder och användare med att minimera inloggningsförfarandet, det ska helst inte märkas. Man vill inte joxa runt med krångliga lösenord och klicka på knappar där det står "Forgot password". Vi kan dock inte alltid ta bort inloggningen för det är ofta ett sätt vi har för att identifiera en användare. Hade det varit roligt att logga in eller om det hade tillfört något av värde för användaren så kunde man ju tänkt sig att bygga en mer märkvärdig inloggningsprocedur, kanske låta användaren logga in lite oftare när de besöker olika sidor?! Tillför det värde för användaren och om det är något bra så vill man ju göra mer av det?! Men så är ju inte fallet här.

En bra user story kan vara input till en spec workshop, backlogg grooming eller liknande som hjälper teamet att förstå vad det rör sig om. En user story beskriver vad, inte hur. En user story hjälper oss att förstå vad kunden och användaren behöver. Hade teamet som byggde tjänsten ovan fått user storyn "As a user I want to register.." i handen så hade de förmodligen aldrig tänkt på att bygga en smidgare lösning, de hade inte kunnat leverera "a better experience". Att för tidigt beskriva saker i detalj och att sätta ramar kan tvärtom vara skadligt. Det man bygger kan bli dyrare och sämre. Mer om det i ett kommande inlägg.. kanske.

Vem vill vad och varför?

Vad kan mer vara galet med nyss nämnda story? Inloggning är alltså inget användaren vill eller har glädje av egentligen. Storyn hjälper oss inte att förstå användaren bättre. Men kan det inte vara bra att den ligger med så att vi inte glömmer bort kravet? Jo det kan självklart vara en viktig del av vårt system. Men det är en constraint (svensk bra översättning av constraint anyone?) och ett icke-funktionellt krav. Är det något som har att göra med säkerhet, prestanda, tillgänglighet m.m. så är det förmodligen ett icke-funktionellt krav. En constraint som vi måste förhålla oss till så klart, men är det något som användaren vill? "As 10.000 simultanous users I want a response time less than 0.5s".

Hur hanterar vi då icke-funktionella krav? Det kan se olika ut beroende på arbetssätt och vilka system man använder. Det kan vara en del av vår Definition of Done (DoD) om det gäller generellt. Berör det en specifik story så kan det vara ett story test som hör det just den storyn. 

Den som inte förstår kan inte göra rätt

Är det viktigt att särskilja olika typer av krav då? Det tycker jag det kan vara, vi vill förstå vem som önskar vad, vem som har vilka behov med mera för att kunna bygga bättre system som löser rätt problem. Hur kan det se ut om man inte förstår sina användare och vad som är viktigt för dem? När FriendFinder blev hackat och information om deras användare blev tillgängligt för kreti och pleti går de ut med följande information:

Källa: troyhunt.com

Källa: troyhunt.com

Ok de förstår uppenbarligen inte vad som är viktigt för deras användare!? En sak är klar och det är att kontonummer och lösenord inte är det viktigaste för användaren. Kontonummer är något som banker har glädje av och lösenord är något som FriendFinder har nytta av. De flesta vettiga banker hanterar bedrägerier och man får sina pengar tillbaka. Det blir än mer tydligt när en site som Ashley Madison blir hackat och de går ut med liknande information. Man kan tycka vad man vill om en sådan sajt och dess användare men uppenbarligen förstår de inte vad som betyder något för användarna. Användarna vill inte att det ska komma ut att de har använt sajten alls. Jag skulle tippa på att de gladeligen skulle välja att bli av med lite cash om de slapp bli av med sin personliga information. Good news your credit card is fine.

Vilka user stories har ovan nämnda sajter haft när de byggt sina system och försökt förstå sig på sina användare? Kanske följande;

  • Som en användare vill jag knappa in mitt ap-långa kontonummer för det ger mig en bisarr tillfredsställelse att ge pengar till folk jag inte känner.
  • Som en användare vill jag registrera mig så jag får ytterligare ett lösenord jag kommer att glömma bort.

Så nästa gång du ser en story som berättar att länkar ska vara blå, att det behövs två databaser eller att man vill klicka i menyer, ställ dig frågan om det är en user story som faktiskt berättar rätt sak om rätt person. Är den sann? Är det systemet eller användaren vi gör det här för? Och är den för detaljerad och berättar för mycket om hur saker ska lösas så kommer du få dåligt resultat i Duncker's Candle problem, flagga för projektledaren tidigt ;)

Hur jobbar du med krav och user stories?

Tveka inte att kontakta oss så berättar vi gärna mer om hur vi jobbar att skapa digitala lösningar genom att involvera användarna och sätta deras behov i fokus. 

2 kommentarer

Skriv kommentar

As a system owner/responsible I want only authenticated users to edit data so that I won't be sent to jail in case of a court verdict.<br /><br />System har ju olika users, inte svårare än så.

Nej jag håller med dig Mattias Nordgren, det behöver inte vara så svårt. Men ibland åker det in saker i backloggen för att man inte ska glömma av dem, eller att man tänker att så länge vi får ner något så blir det bra.<br /><br />Men det kan ju spela rätt stor roll. Din story som du skrev kan ju tänkas få en helt annan prioritering än att en användare ska kunna få tillgång till en viss resurs. Lösningen vi gör kan ju se annorlunda ut om vi vet vem det tillför värde och varför.