Epic vs user story

Förra veckan hamnade jag i en diskussion om skillnaden mellan epic och user story. Vi har delat upp dem så att produktägaren tar fram epics och fyller dem med acceptanskriterier. Sedan skapar vi i teamet upp user storys och tar fram acceptanskriterier för dem. Som scrummästare och agil coach försöker jag driva fram att produktägaren ska skriva grova epics i början av ett projekt och sedan gradvis skapa upp user storys för sin backlog. Därefter borde produktägaren presentera dessa user stories för teamet och förfina dem tillsammans med teamet så att vi kan dra in dem i sprintar.

En epic är som en stor user story, sa jag. Men det höll inte någon i projektledningen med om. Jag tror delvis att det beror på språket. Om man säger epos istället för epic och användarberättelse istället för user story, är det enklare att förstå vad det rör sig om. Ett epos är, liksom Star wars eller Illiaden, en stor berättelse, medan en användarberättelse är en berättelse om en användare som vill ha något. Det är inte konstigare än så. Dessa användarberättelser uppstår när man förfinar eposet och skrivs i formen: som <roll> vill jag <mål/önskan/händelse> för att <syfte>, exempelvis "som en intresserad läsare vill jag hitta intressant information så att jag kan lära mig mer".

Därefter förfinas dessa berättelser av teamet och delas in i små arbetsuppgifter och dras in i en sprint. Eposet dras inte in i någon sprint. Ett epos är alldeles för grovt för det.

När användarberättelsen är klar går teamet tillsammans med produktägaren igenom Definitionen of Done och berättelsens acceptanskriterier. Därefter sätts den till klar.

Demo och godkännande

Efter en sprint är det viktigt att teamet får godkänt på det som gjorts. Det som gjorts ska också demas, dvs. visas upp för alla som är intresserade. Sker det samtidigt? 

När jag började som scrummästare godkände produktägaren inkrementet på demon. Ibland hittade han fel och vi fick bakläxa. Det kändes inte rätt. Problemet var att vi jobbade långt ifrån varandra. Det var först vid demon som produktägaren såg vad teamet gjort. Jag föreslog att vi i teamet kallade produktägaren till ett möte där vi gick igenom det som gjorts i sprinten. På så sätt kunde vi i lugn och ro stämma av det vi gjort i sprinten med produktägarens DoD och acceptanskriterier för användarberättelserna. Produktägaren godkände sprintens inkrement och dagen efter demade vi för alla som ville komma och se och ge återkoppling.

Det blev bättre. Vi slapp känna vi-dom i förhållande till produktägaren. Det blev mer att vi gjorde det tillsammans. Granskningen blev också mer givande eftersom det blev mer av ett samtal än en domstol. 

Vad står INVEST för?

Genom att använda akronymen INVEST är det lättare att komma ihåg de kriterier som krävs för en bra användarberättelse. Om användarberättelse inte uppfyller något av dessa kriterier bör teamet skriva om den.

En bra användarberättelse ska vara:

Indipendent (oberoende av alla andra)
Negotiable (inte ett specifikt kontrakt för funktioner)
Valuable (ge ett värde)
Estimable (möjlig att bedöma ungefärlig storlek på)
Small (för att passa in i en sprint)
Testable (möjlig att testa)

Vad menas med Definition of Ready?

Ett krav (användarberättelse) i backloggen som teamet är överens om att den kan göras klar uppfyller Definition of Ready (DoR). I ett moget, agilt team kanske det inte krävs mer än så, men oftast är det bra med en definition om vad som menas med att ett krav är redo att göras. DoR är inte ett statiskt dokument utan utvecklas liksom teamet med tiden.

Eftersom ett bra krav ska uppfylla det som ingår i INVEST, kan det vara bra att utgå från det.

Independent

Negotiable

Valuable

Estimable

Small

Testable

Exempel:

1. Ett krav ska vara skriven som en användarberättelse, dvs "Som en x vill jag kunna göra y ...".

2. Det ska finnas acceptanskriterier som teamet förstår.

3. Varje användarberättelse ska ha en storlek.

Under sprinten förfinas krav som ligger högt upp i den prioriterade backloggen så att de uppnår DoR. På sprintplaneringen går teamet sedan igenom varje krav som är redo att göras under den kommande sprinten.

Vad menas med Definition of Done?

Vad menas med att något är klart? I min familj kan vi t ex ha lite olika åsikter om vad som menas med att städningen är klar. För att det ska fungera måste vi vara överens om vad som menas med att städningen är klar. Annars är du ju inte klar. Om du klipper halva gräsmattan och diskar halva disken är du inte klar med någondera. Det känns inte bra. Gräsmattan och disken tittar uppfordrande på dig. Det känns bra att bli klar och det är bra att vara överens om vad som menas med klar. I scrum använder man sig av Definition of Done (DoD) för att åstadkomma detta.

När en post i backloggen beskrivs som klar, måste alla förstå vad som menas med att posten är klar. Detta varierar mellan olika team, men medlemmarna i ett team måste ha en gemensam förståelse av vad som menas med att arbetet är klart för att säkerställa transparens. Det är det som är DoD.

Teamets definition av klar används för att bedöma när arbetet med ett inkrement är slutfört eller när en användarberättelse är klar. Samma definition vägleder teamets val av användarberättelser under sprintplanering och som teamet åtar sig att göra under en sprint. Syftet med varje sprint är att leverera ett inkrement av potentiell funktionalitet som uppfyller teamets DoD. Detta inkrement är användbart och ger värde så en produktägare kan välja att leverera det omedelbart.

Det är viktigt att produktägare som har en vision om vad som ska göras och team som vet hur man gör, är överens om en gemensam DoD. DoD är ett slags kontrakt mellan det produktägaren vill och teamet levererar.

Vad är scrum?

Scrum är en metodik skapad av Jeff Sutherland och Ken Schwaber. Ordet "scrum" kommer från rugbyn, och syftar på momentet när bollen sätts i spel. Tanken är att ett tvärfunktionellt team samarbetar för att göra klart produkten på samma sätt som ett rugbylag spelar tillsammans för att föra bollen mot målet.

Syftet med scrum är att få ordning i projekt med kontinuerliga förändringar, till exempel att kunden upptäcker ett förbisett problem under test av en prototyp. Traditionella utvecklingsmetoder bygger på att skriva krav och göra planer, men i praktiken kommer ändringar i krav som skapar oreda i planerna. Planer ger falsk trygghet. Scrum jobbar bara med korta planer och man gör det viktigaste först.

Scrum omfattar ett antal roller och ett antal beståndsdelar:

Roller:

• Produktägare
Hanterar och prioriterar önskemål om tillägg och ändringar för en produkt. Produktägaren måste vara en fysisk person. Produktägaren ansvarar för backlog och för vad som ska göras. 

• Scrummästare
Fungerar som coach för teamet och avlägsnar hinder. Scrummästare ska ha ett agilt tänkesätt. Scrummästaren är ingen teamledare.

• Teamet
Teamet är självorganiserande och tvärfunktionellt. Teamet bör bestå av 3-9 personer. Stora team blir långsamma pga alla interaktioner. Teamet ansvarar för hur det görs. Teamet frågar produktägaren vad som ska göras.

Artifakter:

• Backlog
En samlingsplats för alla önskemål om förändringar av produkten. Produktägaren äger och hanterar backloggen. Det finns ingen begränsning på antal önskemål. I stället används prioritering.

• Sprint-backlog
Den del av en backlog som teamet åtar sig att göra under den kommande sprinten. Uppgifterna som ligger i sprint-backloggen ska vara nedbrutna i deluppgifter och teamet överens om att de är redo att göra (DoR)

• Sprint
Arbetet delas in i sprintar. Varje sprint, som oftast är 2 - 4 veckor lång, inleds med en sprintplanering och avslutas med en sprintgenomgång. Varje sprint bör resultera i något som går att driftsätta.

• Morgonmöte
Ett kort möte för teamet på maximalt 15 minuter för att sprida information. Alla står upp. Alla i teamet svarar på tre frågor:
  - Vad har jag gjort sedan igår?
  - Vad ska jag åstadkomma till imorgon?
  - Vad hindrar mig?
Övriga frågor tas på ett separat möte.

• Sprintgenomgång/demo
En inplanerad granskning av sprintens resultat. Under granskningen visar teamet produktägaren vad som gjorts och produktägaren godkänner funktionaliteten. Sedan visas resultatet i sprinten för alla intressenter. Resultatet av en sprintgenomgång är en ny och uppdaterad backlog om vad som ska göras i nästa sprint.

• Sprintåterblick
Teamet ser tillbaka på det arbete som gjorts under sprinten. Förbättringar identifieras och planeras till kommande sprint.

• Sprintplanering
Ett möte där teamet går igenom de mest prioriterade användarberättelserna i backloggen och drar in dem i sprint-backloggen. Varje användarberättelse bryts ner deluppgifter (sub-tasks) och tidsuppskattas. Antalet användarberättelser som tas in i sprinten avgörs av teamets hastighet.

Begrepp:

Definition of Done

Definition of Ready

Förfining

Användarberättelse
Story points