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.
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.
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 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:
Et eksempel på en brukerhistorie kan være:
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.