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.

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.