I henhold til PRINCE2 er det obligatorisk å benytte seg av produktbeskrivelser. Kravene til produktbeskrivelser er imidlertid svært fleksible, så det er ingenting i veien for å bryte dem ned i det man innen smidig kaller epics og brukerhistorier.
I dette blogginnlegget ser vi nærmere på hvordan man kan bruke PRINCE2s produktbeskrivelser i kombinasjon med smidige brukerhistorier.
Produktfokus
Ett av de fundamentale prinsippene i PRINCE2 er at man har et produktfokus. Dette betyr at man alltid starter med å definere hva som er sluttproduktet som følge av prosjektet, altså produktbeskrivelsen av prosjektet.
Produktbeskrivelser
Når resultatet av prosjektet er beskrevet og godkjent, kan teamet jobbe videre med å detaljere arbeidet som er nødvendig. Prosjektet deles ofte opp i flere team eller grupper som har ulike delleveranser, og hver av disse delleveransene skal ha egne produktbeskrivelser. De godkjente produktbeskrivelsene av hver delleveranse blir dermed kravene eller føringene teamet skal arbeide etter, og prosjektleder lar hvert av teamene selv organisere hvordan de skal arbeide i hver sin leveranse.
Disse beskrivelsene inkluderer ikke bare de funksjonelle og ikke-funksjonelle kravene til produktet, men også kriteriene for hvordan produktet skal verifiseres og godkjennes. Dette kan omfatte testing, kvalitetskontroller og andre relevante prosesser for å sikre at produktet er i samsvar med brukernes behov og forventninger. I PRINCE2 er det også viktig å estimere innsatsen som kreves for å skape hvert produkt eller levere hver delleveranse. Estimater bidrar til å planlegge ressursbruk, definere prosjektskjemaer og sette forventninger til hva som kan oppnås innenfor gitte tidsrammer og ressurser.
Brukerhistorier
Brukerhistorier er en måte å beskrive produktet på. Disse er skrevet fra brukerens perspektiv og brukes til å kommunisere hva brukeren trenger og hvorfor. Dette hjelper teamet med å prioritere arbeidet basert på hva som gir mest verdi for brukeren. Brukerhistoriene er ofte korte og enkle, og kan lett tilpasses etter hvert som prosjektet utvikler seg.
En typisk brukerhistorie følger et slikt standardformat:
- Som en [brukerrolle]: Hvem er brukeren? Dette kan være en spesifikk type bruker, for eksempel en administrator, en sluttbruker, eller en annen interessent.
- ønsker jeg [handling/mål]: Hva vil brukeren oppnå? Dette beskriver handlingen eller målet brukeren har.
- slik at [fordel/verdi]: Hvorfor vil brukeren gjøre dette? Dette beskriver verdien eller fordelen brukeren får ved å utføre handlingen.
Et eksempel på en brukerhistorie kan være:
- Som en kunde: Hvem er brukeren? En kunde som besøker en nettbutikk.
- ønsker jeg å kunne legge varer i handlekurven: Hva vil brukeren oppnå? Brukeren vil kunne legge varer i handlekurven for å kjøpe dem senere.
- slik at jeg kan handle flere varer på én gang: Hvorfor vil brukeren gjøre dette? Brukeren ønsker å samle flere varer i én bestilling for enkelhets skyld og kanskje for å spare fraktkostnader.
I en brukerhistorie er det viktig å også ha med hvordan suksess skal måles og hva som skal til for å godkjenne at brukerhistorien er fullført. Dette inkluderer vanligvis akseptansekriterier, som er klart definerte kriterier som må oppfylles for at brukerhistorien skal anses som ferdigstilt og godkjent.
En brukerhistorie må også inneholde et estimat på hvor mye innsats som kreves for å fullføre arbeidet, inklusiv testing og godkjenning. Å bruke brukerhistorier som produktbeskrivelser sikrer at teamet har en klar forståelse av hva som er leveransen og hvorfor, noe som fremmer samarbeid, effektivitet og fokus på å levere verdi til brukeren.
Hvordan prosjektet deles opp i ulike detaljnivåer av produktbeskrivelser kan illustreres med følgende figur.
Eksempelet over er hentet fra sertifiseringskurset PRINCE2 Agile Practitioner. Ønsker du å lære mer om hvordan PRINCE2 og smidige metoder bør brukes sammen? Da bør du se nærmere på en sertifisering i PRINCE2 Agile.
