Vet du forskjellen mellom et smidig-epos og en brukerhistorie? Eller hvordan du best kan bruke smidige epos for produktkravene og produktveikartet ditt? Hvis du vil lære hvordan du kan bruke smidige epos til din fordel, kan du lese videre for mine sju beste tips og en mal du kan starte med.
Hva er et smidig-epos?
Et smidig-epos er et nyttig verktøy innen smidig prosjektledelse, som brukes til å strukturere den smidige backloggen og veikartet ditt.
Enkelt sagt er et smidig-epos en samling av mindre brukerhistorier som beskriver et stort arbeidselement. Tenk på et epos som en stor brukerhistorie. Epos brukes for eksempel ofte til å beskrive en ny produktfunksjon eller en større funksjonalitet som skal utvikles.
Et epos er det øverste informasjonsnivået i en smidig backlogg. Det inneholder flere brukerhistorier, og hver brukerhistorie inneholder i sin tur alle oppgavene som kreves for implementering.
Smidige epos brukes for det meste når et arbeid er for stort til å leveres i én enkelt sprint eller iterasjon. Hvis du bruker et epos til å gruppere brukerhistoriene dine for en ny funksjon, er det enkelt å følge med på fremdriften og vite hvilken prosentandel av arbeidet som er fullført, sammenlignet med det som gjenstår. Du kan også bruke AI i sprintplanlegging til å skrive og bryte ned smidige epos.
Epos skrives og vedlikeholdes vanligvis av produkteieren eller produktsjefen.
7 beste fremgangsmåter for bruk av smidige epos
Det finnes ingen fast mal for et smidig-epos. Du kan skrive det på den måten du ønsker, så lenge det hjelper med planleggingen av arbeidet og kommunikasjonen med de smidige teamene og interessentene dine.
Uansett om du bruker en Scrum-, Kanban- eller hybridutviklingsprosess, vil epos hjelpe deg med å planlegge arbeidet og rapportere om det.
Her er noen tips for å sikre at de smidige eposene dine er mest mulig nyttige.
Have an account? Log In
1. Start med eposet, og lag deretter brukerhistoriene (ovenfra og ned)
Det kan være svært nyttig å finne eposene dine ved hjelp av et kart over brukerhistorier. «Aktiviteten» på øverste nivå i kartet over brukerhistorier blir et epos, mens de lavere nivåene blir brukerhistoriene, oppgavene og akseptansekriteriene.
Når du utvikler et helt nytt produkt, gir det deg en idé om hvilke milepæler som er fullført og hvilke som gjenstår, hvis du starter med epos og fyller dem ut med mer detaljer etter hvert.
Smidige epos samsvarer ofte med funksjoner eller større forbedringer (for eksempel en redesign av en del av produktet ditt), men det er helt opp til deg hvordan du ønsker å strukturere eposene dine.
2. Gi eposet et godt navn
Når du navngir de smidige eposene dine, bør du tenke på hvem som skal bruke denne informasjonen. De smidige utviklingsteamene dine trenger for eksempel å forstå hva de bygger, og interessentene dine trenger også å forstå fremdriften.
Mens en brukerhistorie beskriver et behov hos sluttbrukeren, er det god praksis at eposet beskriver et resultat du ønsker å oppnå med det.
Vurder disse eksemplene på navn på epos:
- Utsjekkingsflyt V2
- Forenkle utsjekkingsflyten
- Øk konverteringsraten i utsjekkingen
Det første navnet beskriver ikke hva det er, bortsett fra at det gjelder en eller annen form for arbeid med utsjekkingen. Det andre navnet er bedre, ettersom det beskriver at utsjekkingsflyten skal forenkles. Men det tredje navnet er enda bedre, fordi det inkluderer et resultat du ønsker å oppnå med denne forenklingen.
I smidige verktøy for prosjektstyring, som for eksempel Atlassians Jira, kan epos brukes til filtrering, gruppering og rapportering. Derfor er det viktig å velge et navn som taler for seg selv.
3. Sørg for at eposene har riktig størrelse
Et epos brukes vanligvis når arbeidet med et element i backloggen krever mer enn én sprint for å bli fullført. Et epos kan brytes ned i så mange brukerhistorier du ønsker, så lenge du klarer å holde oversikt over hele listen.
Et epos bør verken være for stort eller for lite. En tommelfingerregel kan være en implementeringstid på mellom noen uker og noen måneder. Dette er en god størrelse for rapportering av fullføringsprosenten.
Hvis eposene blir for store, går fremdriften svært sakte, prosentandelene øker knapt i løpet av en to ukers sprint, og rapporteringen blir lite meningsfull. Hvis et epos også tar for lang tid å implementere, vil kravene sannsynligvis endres så mye underveis at rapportering av fremdriften nesten blir meningsløs.
Hvis du gjør eposene for små, vil du ha et stort antall av dem å holde styr på i backloggen eller veikartet ditt. Det kan bli vanskelig å beholde et overordnet perspektiv på mange mindre oppgaver. Hvis epos også fullføres på svært kort tid (f.eks. i løpet av én sprint), tilfører de bare ekstra administrasjon uten å gi særlig verdi.
4. Bruk epos til å strukturere backloggen
Epos er en utmerket måte å strukturere en produktbacklogg på, som vanligvis består av en svært lang liste med brukerhistorier. Ikke alle historier må inkluderes i et epos, ettersom små arbeidsoppgaver ganske enkelt fullføres i løpet av én sprint. Men det å strukturere større arbeidsoppgaver i epos har to hovedfordeler:
- Det gir et overordnet perspektiv på de store oppgavene i backloggen din,
- Ettersom størrelsen på et epos består av summen av historiepoengene for alle brukerhistoriene, gir epos også en sammenligning av den relative størrelsen på initiativer for prioritering.
Listen over epos kan også brukes til å opprette et overordnet perspektiv på et produktveikart for toppledelsen.
5. Bruk epos til å koordinere flere team
Epos kan være svært nyttige for å koordinere arbeidsoppgaver på tvers av flere smidige programvareutviklingsteam. Ved å samle arbeid for flere produktteam i ett enkelt epos kan du bryte ned rapporteringen per team og følge fremdriften samlet.
6. Inkluder suksessmålinger
Når du definerer et epos, er det nyttig å tenke på hvilken suksessmåling som kan knyttes til det. Til syvende og sist skal alle produktleveranser skape verdi for sluttbrukerne. Ved å inkludere en suksessmåling i eposet ditt sikrer du at både medlemmer av utviklingsteamet og interessenter forstår hva du prøver å oppnå med dette arbeidet.
Noen selskaper bruker OKR-er til å sette kvartalsvise mål. Det å referere til en OKR-måling i et epos er en utmerket måte å knytte eposet til forretningsmålene på.
7. Gjør epos fleksible i omfang
Ettersom et epos beskriver en overordnet arbeidsoppgave som fortsetter over flere uker eller måneder, er det sannsynlig at ny innsikt oppstår eller at nye tekniske komplikasjoner avdekkes etter hvert som arbeidet skrider frem. Derfor må et epos ha et fleksibelt omfang.
Omfanget av et epos defineres av omfanget av de tilknyttede brukerhistoriene, vanligvis målt i historiepoeng. Etter hvert som nye krav oppstår, kan nye brukerhistorier legges til, og omfanget av eposet øker.
Relatert lesning: Beste smidige programvare for produktstyring
Mal for smidig epos
Det finnes ikke noe fast format for et epos, men noen elementer er nyttige, slik det er beskrevet ovenfor.
- Velg et godt navn som taler for seg selv.
- Gi i beskrivelsen en grov oversikt over hva eposet omfatter. Nevn eventuelle selskapsmål for å illustrere hvordan dette henger sammen med forretningsprioriteringene.
- Suksessmålingen beskriver spesifikt hva som skal måles etter at dette eposet er fullført.
- En stor brukerhistorie angir en brukerhistorie på nivået til hele eposet. Dette er svært nyttig for å dokumentere hvordan eposet gir en bedre brukeropplevelse.
More Articles
Eksempel på et smidig epos
Her er et eksempel på et epos for en ny og forenklet betalingsflyt i en mobilapp, med mål om å øke konverteringen.
Innenfor dette eposet kan vi deretter ha brukerhistorier som:
- Integrere Apple Pay («Som kjøper ønsker jeg å betale med ett trykk på telefonen, slik at jeg kan fullføre betalingen raskt»)
- Bruke fakturaadressen som leveringsadresse som standard («Som kjøper ønsker jeg å oppgi adresseopplysningene mine bare én gang, slik at jeg kan fullføre betalingen raskt»)
Konklusjon
Smidige eposer er et fleksibelt verktøy i den smidige verktøykassen din. Når du starter en større ny utvikling, bør du tenke på de store arbeidsdelene som kreves for å fullføre den, og definere noen få eposer. Deretter kan du opprette alle brukerhistoriene dine innenfor disse eposene etter hvert som du arbeider videre, og beholde en langt bedre oversikt enn i en ustrukturert arbeidskø.
Eposer kan brukes på mange måter. Jeg vil gjerne høre hvordan dere bruker eposer i de smidige teamene deres, i kommentarfeltet.
For flere artikler med praktisk informasjon om et stort utvalg av temaer innen produktledelse – inkludert smidig metodikk! – abonner på nyhetsbrevet vårt.
Sjekk også ut:
