Hva er forskjellene mellom smidig epos og bruker historier? User stories er en grunnleggende del av alle smidig utvikling. De er lette krav som representerer ny funksjonalitet som gir verdi til virksomheten interessenter, inkludert end-brukere. De er byggesteinene som blir prioritert i produktkøen og brakt inn spurter, og de fokuserer på utvikling teamet på å gi verdi for bedriften.
Så hva er en episk?,
Hvis du henger rundt smidige utviklere, du er nødt til å høre det ordet, også, fra tid til annen. Og de høres ut akkurat som bruker historier. Men er de det? I dette innlegget, jeg vil dykke inn i forskjellene mellom epos og bruker historier: hva de er, hvordan de er i slekt, og hvorfor du trenger, både for smidige utviklingsprosjekter.
Hva er en Bruker Historien?
Tidligere, jeg delte en grundig titt på hva brukeren historier og hvordan de er laget.,
for Å oppsummere, kan en bruker historien starter med et enkelt uttrykk i form av:
Som jeg vil , så jeg
denne setningen vi legge til en rekke informasjon, bestående av kriterier for aksept og utvikling lagets diskusjon notater.
Når disse elementene er alle på plass, brukeren historien er vurdert som klar for produksjon. Det kan da bli inkludert i neste sprint… hvis det er prioritert høyt nok av produkteier.
Hva er en Episk?
En epic er en stor bruker historien., Begrepet brukes ofte for å beskrive utrolig lange historier, som Tapte Paradis, skrevet av det 17. århundre engelske poeten John Milton. Milton ‘ s «epic» dikt, som opprinnelig besto av mer enn ti bind med mer enn ti tusen ord.
når det gjelder utvikling av programvare, skjønt, er den større historien, desto mer sannsynlig er det at du ser på en episk. Dette er den mest vesentlige forskjellen mellom smidig epos og bruker historier.
det er det. Ingenting fancy her. Ingen trenger å få bundet opp i knop prøver å finne ut», Bør dette være en episk eller en fortelling?,»Hvis det er noe som gir verdi for bedriften, og må være på produktkøen, det er en bruker historien. Men det kan også være en episk, fordi det er stort.
Så hva betyr «stor» egentlig betyr?, I de årene jeg har vært ved hjelp av Scrum, de beste to definisjonene jeg har funnet er:
- En episk er en historie som er større enn 8 historien poeng
- En episk er en historie som ikke kan være ferdig i en sprint
jeg tror den andre definisjonen er bedre, siden det ikke er avhengige av din bruk av historien poeng for estimering (selv om du kan lese hvorfor jeg elsker historien punkt estimering) og det er uavhengig av det aktuelle lagets hastighet.
Epos kan variere fra bruker historier som nesten ikke er liten nok til å passe i en sprint, til stor «høyt nivå» epos som omfatter store funksjoner.,
Sjekk ut min bok Den Episke Guide for å Smidig å lære mer!
Start Med Epos Før du Bruker Historier
Når du først begynner å planlegge for et smidig utvikling prosjekt, som alle bruker-historier vil sannsynligvis være i episk form. Deretter, som produkteier begynner å prioritere de viktigste av disse epos vil bli brutt ned, ned, ned i mye mindre brukeren historier.
produkteier så prioriterer de historiene og de høyeste prioritet de vil gjøre det i neste sprint.,
En av de chief fordeler av epos er at de holde produktkøen fra å bli rotete. Tenk hva som ville skje hvis du har brutt hver eneste av dine epos ned i sprint-størrelse bruker historier i begynnelsen av et prosjekt. Først, ditt produkt backlog ville være utrolig uhåndterlig, noe som gjør produktet ditt eierens jobben med å prioritere mye vanskeligere. For det andre, den tid det ville ta å skrive og diskutere alle de som bruker historier ville være som… vel, tradisjonelle utvikling av et prosjekt.,
Ved å holde de fleste av bruker historier i episk form, gjør du det mye enklere for produkteier for å administrere produktkøen. Viktigst av alt, du fortsette din utvikling team fra å kaste bort tiden sin på å meisle ut et stort antall av brukeren historier som kanskje aldri bli prioritert i det hele tatt. I starten av et prosjekt, jeg liker å lage et produkt backlog består av 50 til 75 historier ideelt sett, og ikke mer enn 100 på den høye enden.,
Når Bryte Skrev Ned
Det er bare en passende tidspunkt å bryte en episk ned i sprint-størrelse bruker historien biter: når produktet eier føler at en episk nærmer seg toppen av ordrereserven. På den måten bevegelsen av en episk mot toppen av ordrereserven er en annen forskjell mellom smidig epos og bruker historier.
Inntil det skjer, bruker historier er bedre bosatt i episk form. Men når en episk klatrer inn i de øverste lagene av produktkøen, det er på tide å begynne å bryte det ned.,
Du trenger ikke å bryte hele episke ned i sprint-store biter, men. Faktisk, du bør ikke. Noen av user stories i den episke kommer til å være høyere prioritering enn andre. Og noen av brukeren historier du finner i den episke vil være mye lavere enn andre prioriteringer på listen din.
Du vil chip bort på din epos som en skulptør chips bort på stein for ikke å skape noe nytt, men å avdekke de viktigste delene skjult inne. Som Michelangelo sa en gang, «Hver blokk av stein har en statue inne i det, og det er en oppgave av billedhuggeren å oppdage det.,»
Så, også, må produktet eieren trenger til chip bort på din epos til å oppdage den viktigste brukeren historier inne. De – og bare de – er brukeren historier som bør være fleshed ut, diskutert og gjort klar for en sprint.
Og når du chip noen bruker historier ut i en episk hva skjer med resten? Ingenting skjer det… det er fortsatt i produktkøen som en episk. Etter neste sprint, produktet eier kan velge å chip ut noen flere bruker historier fra det., Eller kanskje den episke mister noen relevans uten de viktigste delene og synker lengre ned på prioriteringslisten.
uansett, er avgjørelsen av hva du skal gjøre med en episk vil bli gjort basert på at epic sin posisjon i produktkøen og ingenting annet.
Epos og Bruker Historier: En Tandem-Effektivitet
Så der har du det.
Hva er en episk? Det er en stor bruker historien som ikke er klar for, og som ikke kan passe inn i en produksjon sprint., Du store epos i produktkøen fordi de gir deg en enorm effektivitet øke, slik at Scrum utvikling team bort fra lavere prioritet distraksjoner.
Og når en episk nærmer seg toppen av den prioriterte listen, trenger du ikke å bryte det hele ned. Du bare bryte ut så mange høyt prioritert bruker historier som du trenger. Da produktet eier prioriterer både fullført bruker historier og det som er igjen av den episke i produktkøen.
På denne måten, ved å kombinere epos og bruker historier skaper en tandem av effektivitet for dine Scrum utvikling team., Mens lignende i naturen, epos og de mindre, sprint-størrelse bruker historier tjene to svært ulike formål.
Hvis du har slitt med å realisere forretningsverdi raskt med produktutvikling lagene, ta kontakt med oss i dag.