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 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.