I dette indlæg skal vi kigge på, hvad Epics og User stories er for en størrelse, og hvordan du bruger dem i dine projekter.
Lad os sige, at du og dit team vil gøre noget så ambitiøst, som at sende en raket ud i rummet. For at kunne komme i mål med, at ambitiøst projekt skal du strukturere dit arbejde, sådan at du sikrer dig, at du ikke glemmer noget.
Dette gør du ved at dele det store projekt ned i bidder først i store bidder (Epics) og derefter ned i mindre bidder (User stories).
Herunder er der en video, der går i dybden med emnet:
Hvad er User stories?
User stories er enkeltstående krav til projektet, det kunne eksempelvis være “Jeg vil som bruger gerne kunne betale med MobilePay”. Det er i disse User stories at du skriver opgaven helt ned til den sidste detalje.
Hvad er Epics?
Epics er en samling af User stories, som grupperer dine krav til projektet. Med eksemplet ovenfor med MobilePay ville den Epic eksempelvis hedde “Kassen”, og i den Epic ville der være mange andre User stories, såsom “Jeg vil som bruger gerne kun skulle skrive postnr. og at den finder bynavn selv”
Hvornår bruger du disse værktøjer?
Du kommer til at bruge User stories og Epics forud for dine projekter, når du skal til at planlægge dem sammen med din leverandør til projektet. Jeg gør det tit sammen med en medarbejder, som er ekspert inden for emnet, typisk en sælger i virksomheden, hvor jeg arbejder. Der tager jeg bare en snak med ham og spørger ind til hvad han tror kunderne gerne vil have, og hvorfor.
Men lad os kigge lidt nærmere på disse to, ved at dykke ned i dem hver især. De er heldigvis ikke så komplicerede, så det er hurtigt overstået.
Epics
Som du kan læse lige ovenfor, så minder Epics meget minder meget om opdeling mellem “Leverancer” og “Opgave” fra min Work Breakdown Structure, som jeg skrev om i indlægget: Lær hvordan du estimerer dine projekter.
En Epic er med andre ord en samling opgaver/stories, som er grupperet efter projektets del-leverancer. Det er vigtigt at du sikrer dig at dine Epics understøtter projektets målsætninger. For det er på den måde at du i virkeligheden sikrer dig at projektet bliver en succes.
Hvorfor skal man lave Epics?
Grunden til at Epics er så vigtige, er at den giver dig et overblik over opgaverne, og hvor langt du er med alle leverancerne af projektet. Man bruger tit Burndown charts til at visualisere fremgangen i projektet og i enkelte Epics. Dette giver dig et rigtig godt billede af hvorvidt du kan lancere projektet til tiden, og eventuelt hvilke opgaver eller Epics, som du ikke kan nå at få med i projektet.
Eksempel på Epics
Lad os antage at du skal til at drive et digitalt projekt, hvor du skal lancere en ny webshop. I dette eksempel ville det give mening at have følgende epics som eksempel:
- Indholdssider & Blog
- Kategorisiden
- Produktsiden
- Checkout
- Betaling & Fragt
- Integrationer
Hver af disse Epics skal så uddybes med individuelle stores, som jeg nok skal skrive mere om nedenfor. Men det kunne som eksempel under “Produktsiden” være:
- “Jeg vil som kunde, gerne kunne se et produktbillede, så jeg kan se at det er det produkt jeg gerne vil have.”
- “Jeg vil som kunde, gerne kunne læse en kort beskrivelse, så jeg kan bekræfte at det er den model jeg er ude efter.”
- Jeg vil som kunde, gerne kunne lægge varen i kurven, så jeg kan bestille varen hjem.”
Men en Epic er ikke bare en gruppering af opgaver, der er tit også knyttet en beskrivelse af emnet.
Så her skal du gerne skrive lidt overordnet omkring de underliggende opgaver/stories, og hold dem gerne op mod projektets målsætninger.
Et eksempel kunne være: “En optimeret og mobilvenlig produktsiden skal være med til at løfte vores salg gennem digitale kanaler med over 15% i det kommende år. Det er derfor vigtigt at vi sikrer en god kundeoplevelse på disse sider, sådan at kunderne bliver inspireret, og ender med at købe vores produkter.”
Som du kan se, så relatere alle disse opgaver dig til produktsiden, så derfor kan man samle dem der under den Epic, og gennem let følge op på hvor langt man er nået med den del af projektet.
User stories
Det næste vi så skal kigge på, er hvad en User story er for en størrelse. Du har jo allerede fået for forsmag på det her tidligere i dette indlæg, men nedenfor vil jeg gå lidt mere i dybden med det.
User stories er en uformel og generel forklaring af den ønskede feature som kunden eller du gerne vil have.
Som udgangspunkt er user stories meget kundefokuseret eller brugerfokuseret. Det ligger også lidt i navnet, de hedder jo ikke business stories.
Så det gode ved User stories er at de tvinger dig til at se alle opgaver fra brugeren eller kundens perspektiv, og på den måde får tænkt dem med ind i projektet.
Så du kan ikke bare tage din kravspecifikation og sige at det var det. Nej, du skal formulere dine krav om til brugerens ønsker.
En User story er tit ikke skrevet i et teknisk sprog, eller som direkte løsningsforslag, de skrives som oftest som ønsker, potentielle kunder eller brugere kunne have.
User stories er også tit relativt korte, de består kun af et par sætninger. Så de går typisk ikke ned i detaljer om hvordan man løser en opgave, men fokusere udelukkende på hvilken effekt opgaven skal have på brugeren eller kunden.
Hvorfor skal man lave User stories?
For folk som ikke er vant til at arbejde med agile projekter, og som ikke er vant til at lave User stories, så kan det godt virke som unødigt arbejde at lave dette. Især når man allerede har lave en kravspecifikation. Men det er det ikke. User stories hjælper dig med at holde fokus på brugere eller kunden. De har fokus på at finde på innovative løsninger fremfor at fokusere på nuværende problemer.
Eksempel på en User story
User stories er typisk formuleret ved at bruge en foruddefineret sætning:
“Som en [persona], vil jeg gerne [kunne gøre], [sådan at]”
Som du kan se, er der tre steder som er indkapslet i […], og det er fordi at de ændre sig for hver User story. Herunder kan du se definitionerne på dem:
- [Persona] – Hvem skal have fordel af denne opgave? Kunderne, en medarbejder i virksomheden eller en helt tredje? Med persona sætter du scenen for hvem der er interesseret i denne opgave. Hvis man har flere segmenter eller kundetyper som man har fundet gennem en persona-analyse, så kan man sagtens bruge disse. Ofte har virksomheder 5-8 personaer på deres kunder.
- [Kunne gøre] – Hvad vil du gerne løse med opgaven? Det er denne del der beskriver selve opgaven, og som giver et hint til hvordan den skal løses. Men det er vigtigt at du ikke beskriver hvordan det skal løses rent teknisk, da fokusset på denne User story er brugeren, og ikke løsningen. I skal nok få kigget på hvordan I løser opgaven med jeres leverandør når i kommer dertil.
- [Sådan at] – Hvilken fordel forventer du at opgaven har for din persona? Denne del tvinger dig til at tænke over hvorfor det egentlig er at du har dette som et krav. Det hjælper dig blandt andet som projektleder til at prioritere de forskellige User stories, da det giver dig et klar indblik i hvor vigtig en given story er i forhold til de andre.
Lad os lige se på mine eksempler fra tidligere igen:
- “Jeg vil som kunde, gerne kunne se et produktbillede, så jeg kan se at det er det produkt jeg gerne vil have.”
- “Jeg vil som kunde, gerne kunne læse en kort beskrivelse, så jeg kan bekræfte at det er den model jeg er ude efter.”
- Jeg vil som kunde, gerne kunne lægge varen i kurven, så jeg kan bestille varen hjem.”
Der kan du tydeligt se hvordan jeg har bygget dem op efter skabelonen ovenfor.
Du kan under hver User story tilknytte en længere beskrivelse hvis det er nødvendigt, og der kan indgå en smule tekniske noter eller løsningsforslag.
Men som udgangspunkt skal du helst undgå dette.
Denne skabelon er ikke et krav, du kan også sagtens lave User stories uden, men den tvinger dig bare til at lave dem korrekt hvis du følger den. Så mit råd herfra er helt sikkert at bruge den næste gang.
Dette gør det nemmere hvis du sidder og skriver en masse User stories på en gang. Til at større projekt kan du nemlig nemt skrive flere hundrede User stories, så du kan bestemt spare lidt tid ved at bruge den.
Opsummering
Dette emne er et, som flere af mine læsere har efterspurgt, og det kan jeg sagtens forstå.
Epics og User stories er ikke noget, som falder og naturligt at lave især ikke, når man allerede har lavet en kravspecifikation.
Men hvis du vil have det meste ud af dit projekt, så vil jeg anbefale dig at lave dem, de sætter bare et helt andet lys på projektet, og de forvandler projektet om fra at være et virksomhedsprojekt til et projekt, man laver for kunden eller brugerne.
User stories tvinger dig nemlig til at tænke på din [persona] først og fremmest, frem for at tænke på de arbejdsgiver.
Men hele tankegangen er jo netop, at hvis du tænker primært på din [persona], så tænker du også indirekte på virksomheden, da den vil stå stærkere.
Men tag og give User stories og Epics en chance, næste gang du skal drive et projekt, jeg kan i hvert fald varmt anbefale det.
