Hvad er forskellene mellem agile epics og brugerhistorier? Brugerhistorier er en grundlæggende komponent i enhver smidig udvikling. Det er lette krav, der repræsenterer ny funktionalitet, der leverer værdi til forretningsinteressenter; inklusive slutbrugere. De er byggestenene, der bliver prioriteret på produkt backlog og bragt ind i sprints, og de fokuserer udviklingsteamet på at give forretningsværdi.
Så hvad er en episk?,
Hvis du hænger rundt agile udviklere, er du bundet til at høre dette udtryk, også fra tid til anden. Og de lyder ligesom brugerhistorier. Men er de? I dette indlæg vil jeg dykke ned i forskellene mellem epos og brugerhistorier: hvad de er, hvordan de er relaterede, og hvorfor du har brug for begge til dine agile udviklingsprojekter.
Hvad er en brugerhistorie?
tidligere delte jeg et dybtgående kig på, hvilke brugerhistorier der er, og hvordan de er oprettet.,
for at opsummere starter en brugerhistorie med en simpel erklæring i form af:
som en, vil jeg , så jeg
til denne erklæring tilføjer vi en række detaljer , der består af acceptkriterierne og udviklingsholdets diskussionsnotater.
Når disse elementer er alle på plads, betragtes brugerhistorien som klar til produktion. Det kan derefter inkluderes i den næste sprint… hvis det prioriteres højt nok af produktejeren.
Hvad er en episk?
en episk er en stor brugerhistorie., Udtrykket bruges ofte til at beskrive utroligt lange historier, som Paradise Lost, skrevet af den engelske digter John Milton fra det 17.århundrede. Miltons “episke” digt bestod oprindeligt af mere end ti bind med mere end ti tusind vers.
da det vedrører soft .areudvikling, jo større historien er, desto mere sandsynligt ser du på en episk. Dette er den væsentligste forskel mellem agile epics og brugerhistorier.
det er det. Der er ikke noget særligt her. Ingen grund til at blive bundet i knuder og forsøge at finde ud af, “Skulle dette være en episk eller en historie?,”Hvis det er noget, der giver forretningsværdi og skal være på product backlog, er det en brugerhistorie. Men det kan også være en episk, fordi den er stor.
Så hvad betyder” stor ” faktisk?, I de år, jeg har været med Scrum, de bedste to definitioner, jeg har fundet er:
- En episk er en historie, der er større end 8 story points
- En episk er en historie, der ikke kan være afsluttet i en sprint
jeg tror, at den anden definition er bedre, da det ikke er afhængig af din brug af story points for skøn (dog kan du læse, hvorfor jeg elsker historie punkt estimering), og det er uafhængigt af netop dit team ‘ s hastighed.
Epics kan variere fra brugerhistorier, der er næsten små nok til at passe ind i en sprint, til enorme “højt niveau” epics, der omfatter store funktioner.,
tjek min bog Den episke Guide til Agile for at lære mere!
Start med Epics før brugerhistorier
Når du først begynder at planlægge et smidigt udviklingsprojekt, vil alle dine brugerhistorier sandsynligvis være i episk form. Derefter, som produktejeren begynder at prioritere, vil de vigtigste af disse epos blive opdelt, ned, ned i meget mindre brugerhistorier.
produktejeren prioriterer derefter disse historier, og de højeste prioriterede vil gøre det til den næste sprint.,
en af de vigtigste fordele ved epics er, at de holder dit produkt backlog fra at blive rodet. Tænk, hvad der ville ske, hvis du brød hver eneste af dine epos ned i sprintstore brugerhistorier i starten af et projekt. For det første ville din produkt backlog være utrolig uhåndterlig, hvilket gør din produktejers job med at prioritere meget sværere. For det andet ville den tid det tager at skrive og diskutere alle disse brugerhistorier være som… godt, traditionel projektudvikling.,
Ved at holde de fleste af dine brugerhistorier i episk form, gør du det meget lettere for produktejeren at administrere Product backlog. Endnu vigtigere, du holder dit udviklingshold fra at spilde deres tid hashing ud et stort antal brugerhistorier, der måske aldrig prioriteres overhovedet. I starten af et projekt kan jeg godt lide at oprette en produkt backlog bestående af 50 til 75 historier ideelt og ikke mere end 100 i den høje ende.,
Hvornår skal du bryde dine Epics ned
Der er kun en passende tid til at bryde en epic ned i sprintstore brugerhistoriebunker: når produktejeren føler, at en epic nærmer sig toppen af Backloggen. På den måde er bevægelsen af et epos mod toppen af Backloggen en anden forskel mellem agile epics og brugerhistorier.
indtil det sker, er dine brugerhistorier bedre at bo i episk form. Men når en episk klatrer ind i den øverste rækkevidde af dit produkt backlog, er det tid til at begynde at bryde det ned.,
Du behøver dog ikke at bryde hele epikken ned i sprintstore bidder. Nogle af brugerhistorierne inden for det episke vil være højere prioriteter end andre. Og nogle af de brugerhistorier, du finder inden for det episke, vil være meget lavere end andre prioriteter på din liste.
du ønsker at chip væk på dine epics som en billedhugger chips væk på stone – ikke at skabe noget nyt, men at afsløre de vigtige dele skjult inde. Som Michelangelo engang sagde, ” Hver stenblok har en statue inde i den, og det er billedhuggerens opgave at opdage den .,”
så skal din produktejer også chip væk på dine epics for at opdage de vigtigste brugerhistorier inde. Disse – og kun dem-er brugerhistorierne, som skal konkretiseres, diskuteres og gøres klar til en sprint.
og efter at du har chip nogle brugerhistorier ud af en episk, Hvad sker der med resten? Der sker ikke noget med det … det forbliver i produkt backlog som en episk. Efter den næste sprint kan din produktejer vælge at chip nogle flere brugerhistorier ud af det., Eller måske mister epikken en vis relevans uden de vigtige dele og falder længere ned på prioritetslisten.
uanset hvad vil beslutningen om, hvad man skal gøre med en epic, blive taget ud fra den episke position inden for produkt Backloggen og intet andet.
Epics og brugerhistorier: en Tandem af effektivitet
så der har du det.
Hvad er en episk? Det er en stor brugerhistorie, der ikke er klar til – og ikke kan passe ind i – en produktionsprint., Du gemmer epics i dit produkt backlog, fordi de giver dig en enorm effektivitet boost, holde din Scrum udviklingsteam væk fra lavere prioritet distraktioner.
og når en episk nærmer sig toppen af din prioritetsliste, behøver du ikke at nedbryde det hele. Du bryder simpelthen ud så mange brugerhistorier med høj prioritet, som du har brug for. Derefter prioriterer produktejeren både de færdige brugerhistorier og hvad der er tilbage af det episke i produkt Backloggen.
på denne måde skaber kombination af epics og brugerhistorier en tandem af effektivitet for dit Scrum-udviklingshold., Mens lignende i naturen, epics og deres mindre, sprint-størrelse brugerhistorier tjener to tydeligt forskellige formål.
Hvis du har kæmpet med at realisere forretningsværdi hurtigt med dine produktudviklingsteams, skal du kontakte os i dag.