vilka är skillnaderna mellan smidiga epics och användarhistorier? Användarhistorier är en grundläggande del av någon smidig utveckling. De är lätta krav som representerar ny funktionalitet som ger värde till affärsaktörer, inklusive slutanvändare. De är byggstenarna som prioriteras på produktstocken och tas in i sprints, och de fokuserar Utvecklingsteamet på att ge affärsvärde.
så vad är en episk?,
om du hänger runt agila utvecklare, är du skyldig att höra den termen också, från tid till annan. Och de låter precis som användarhistorier. Men är de? I det här inlägget dyker jag in i skillnaderna mellan epics och användarhistorier: vad de är, hur de är relaterade och varför du behöver både för dina smidiga utvecklingsprojekt.
Vad är en användarhistoria?
tidigare delade jag en djupgående titt på vilka användarhistorier som är och hur de skapas.,
för att sammanfatta, en användarhistoria börjar med ett enkelt uttalande i form av:
som en , Jag vill , så jag
till detta uttalande lägger vi till en mängd detaljer, bestående av acceptanskriterier och utvecklingsteamets diskussionsnoter.
När dessa element är på plats anses användarhistorien vara klar för produktion. Det kan sedan ingå i nästa sprint… om det prioriteras tillräckligt högt av produktägaren.
Vad är en episk?
en episk är en stor användarhistoria., Termen används ofta för att beskriva otroligt långa berättelser, som Paradise Lost, skrivet av den engelska poeten John Milton från 1700-talet. Miltons ”episka” dikt bestod ursprungligen av mer än tio volymer med mer än tio tusen verser.
När det gäller mjukvaruutveckling, desto större är historien, desto mer sannolikt tittar du på en episk. Detta är den mest signifikanta skillnaden mellan agile epics och användarhistorier.
det är det. Inget fint här. Inget behov av att bli bunden i knutar försöker räkna ut, ” bör detta vara en episk eller en historia?,”Om det är något som ger affärsvärde och måste vara på produkten eftersläpning, det är en användarhistoria. Men det kan också vara en episk, eftersom det är stort.
Så vad betyder” big ” egentligen?, Under åren har jag använt Scrum, de bästa två definitionerna jag har hittat är:
- en episk är en historia som är större än 8 storypoäng
- en episk är en historia som inte kan slutföras i en sprint
Jag tror att den andra definitionen är bättre, eftersom den inte är beroende av din användning av storypoäng för uppskattning (även om du kan läsa Varför jag älskar storypunktsuppskattning) och det är oberoende av ditt specifika lags hastighet.
Epics kan variera från användarhistorier som är nästan små nog att passa i en sprint, till stora ”hög nivå” epics som omfattar stora funktioner.,
kolla in min bok The Epic Guide to Agile för att lära dig mer!
börja med Epics innan användarhistorier
När du först börjar planera ett smidigt utvecklingsprojekt kommer alla dina användarhistorier sannolikt att vara i episk form. Sedan, när produktägaren börjar prioritera, kommer det viktigaste av dessa epics att brytas ner, ner, ner i mycket mindre användarhistorier.
produktägaren prioriterar sedan dessa berättelser och de högsta prioriterade kommer att göra det till nästa sprint.,
en av de främsta fördelarna med epics är att de håller din produkt eftersläpning från att bli rörig. Tänk vad som skulle hända om du bröt varenda en av dina epos ner i sprint-storlek användarhistorier i början av ett projekt. Först, din produkt eftersläpning skulle vara otroligt otymplig, vilket gör din produkt ägarens jobb att prioritera mycket svårare. För det andra, den tid det skulle ta att skriva och diskutera alla dessa användarhistorier skulle vara som… Tja, traditionell projektutveckling.,
genom att hålla de flesta av dina användarhistorier i episk form gör du det mycket lättare för produktägaren att hantera produktstocken. Ännu viktigare, du hålla ditt utvecklingsteam från att slösa sin tid hashing ut ett stort antal användarhistorier som aldrig kan prioriteras alls. I början av ett projekt, jag gillar att skapa en produkt eftersläpning består av 50 till 75 Våningar helst, och inte mer än 100 i high end.,
när du ska bryta dina epos ner
det finns bara en lämplig tid att bryta en episk ner i sprintstora användarhistorikbitar: när produktägaren känner att en episk närmar sig toppen av eftersläpningen. På så sätt är rörelsen av en episk mot toppen av eftersläpningen en annan skillnad mellan smidiga epics och användarhistorier.
tills det händer är dina användarhistorier bättre bosatta i episk form. Men när en episk klättrar in i de övre delarna av din produkt eftersläpning, är det dags att börja bryta ner det.,
du behöver inte bryta hela epic ner i sprintstora bitar, dock. I själva verket borde du inte. några av användarhistorierna inom den episka kommer att vara högre prioriteringar än andra. Och några av användarhistorierna hittar du inom den episka kommer att vara mycket lägre än andra prioriteringar på din lista.
du vill chip bort på dina epos som en skulptör chips bort på sten – inte för att skapa något nytt, men för att avslöja de viktiga delarna gömda inuti. Som Michelangelo en gång sa, ” varje stenblock har en staty inuti den och det är skulptörens uppgift att upptäcka den.,”
så behöver din produktägare också chip bort på dina epics för att upptäcka de viktigaste användarhistorierna inuti. Dessa – och bara de-är användarberättelserna som ska kösas ut, diskuteras och göras redo för en sprint.
och efter att du chip några användarhistorier ur en episk vad händer med resten? Ingenting händer med det … det förblir i produktstocken som en episk. Efter nästa sprint kan din produktägare välja att chip ut några fler användarhistorier från den., Eller kanske epic förlorar viss relevans utan de viktiga delarna och faller längre ner i prioriteringslistan.
hur som helst kommer beslutet om vad man ska göra med en episk att fattas baserat på Epics position inom produktstocken och inget annat.
Epics and User Stories: en Tandem av effektivitet
Så där har du det.
vad är en episk? Det är en stor användarhistoria som inte är redo för – och kan inte passa in i – en produktionssprint., Du lagrar epics i din produkt eftersläpning eftersom de ger dig en enorm effektivitetshöjning, vilket håller ditt Scrum – utvecklingsteam borta från lägre prioriterade distraktioner.
och när en episk närmar sig toppen av din prioritetslista behöver du inte bryta ner hela saken. Du bryter helt enkelt ut så många högprioriterade användarhistorier som du behöver. Då prioriterar produktägaren både de färdiga användarhistorierna och vad som återstår av epiken i produktstocken.
På så sätt skapar en kombination av epics och användarhistorier en tandem av effektivitet för ditt Scrum-utvecklingsteam., Medan liknande i naturen, epics och deras mindre, sprint-sized användarhistorier tjänar två distinkt olika syften.
om du har kämpat med att realisera affärsvärde snabbt med dina produktutvecklingsteam, kontakta oss idag.