INVEST er en metode til at skabe gode User Stories. Det gør det muligt at kontrollere, om de har korrekt formuleret indhold, og om de relaterer sig til forretningsværdien af produktet. Og også, om deres størrelse og anvendelighed er valgt korrekt.
Oprettelse af den bedste User Story med INVEST – indholdsfortegnelse:
- Introduktion
- I for Uafhængig
- N for Forhandlingsbar
- V for Værdifuld eller Vertikal
- E for Estimerbar
- S for Lille
- T for Testbar
- Sammendrag
Introduktion
INVEST er et akronym skabt af Bill Wake i 2003. Hver bogstav i det står for begyndelsen af et ord, der karakteriserer en god User Story. Ifølge INVEST-princippet bør hver User Story være:
- Uafhængig
- Forhandlingsbar
- Værdifuld
- Estimerbar
- Lille
- Testbar
Vi har skrevet mere om, hvad en User Story er i en separat artikel. Her vil vi kun nævne, at det er en kortfattet beskrivelse af en ny produktfunktionalitet skrevet i et tilgængeligt sprog.
I for Uafhængig
Den første egenskab ved en god User Story er dens uafhængighed. Det betyder, at dens beskrivelse og karakteristika skal være forståelige uden reference til andre User Stories. Men mest af alt, realisationen bør ikke korrelere med andre User Stories. Selvfølgelig vil det ikke være fuld uafhængighed. Du kan ikke opdele produktoprettelse i helt separate moduler. Det er dog afgørende at huske på at holde User Stories så uafhængige som muligt. Takket være det, selvom en af dem ikke går ind i implementeringsfasen eller bliver væsentligt ændret, vil de resterende ikke skulle ændres. Som regel skal en User Story udgøre en separat og sammenhængende helhed.
N for Forhandlingsbar
En User Story skal være forhandlingsbar. Det betyder, at den sætter målet, ikke måden at nå dertil.
Med andre ord definerer den en forventet funktionalitet af produktet, ikke en teknisk løsning til implementering.
Forhandlingen om User Story finder sted mellem Product Owner og udviklingsteamet. Product Owner foreslår implementeringen af en bestemt funktionalitet af produktet, dvs. siger “Hvad” der skal gøres. Udviklerne er ansvarlige for at besvare “Hvordan” spørgsmålet. Det vil sige, forhandle specifikke måder at løse problemet præsenteret i User Story.
V for Værdifuld eller Vertikal
I akronymet INVEST står bogstavet V for to kvaliteter:
- Værdifuld
- Vertikal
Begge afslører nøglekarakteristika ved en god User Story. Derfor har vi besluttet at forklare, hvad hver af dem betyder.
Værdifuld
En værdifuld User Story retfærdiggør forretningsformålet med ændringen. Med andre ord besvarer den præcist spørgsmålet om, hvorfor ændringen skal introduceres, og hvorfor den er vigtig fra interessenternes synspunkt.
Vertikal
Den anden egenskab; Vertikal stammer fra Agile-metodologien. Den vertikale User Story indeholder en ny funktionalitet af produktet, der er synlig for brugeren. Det vil sige, at den ikke fokuserer på horisontal “ydelsesforbedring” i et valgt lag af produktet. Tværtimod tilføjer den et andet “lag” til det.
Med andre ord beskriver User Story, hvordan man ændrer den overordnede drift af et produkt ved at besvare spørgsmålet Hvad præcist skal forbedres? Det betyder også, at hver funktionalitet af produktet bygger på eksisterende løsninger.
E for Estimerbar
En god User Story skal være estimerbar. Det betyder, at den klart skal definere omfanget af ændringer, der skal foretages i produktet, for at User Story kan betragtes som fuldført. Dette gør det muligt for udviklingsteamet at bestemme den tid og indsats, der kræves for at fuldføre den.
Omfanget og sværhedsgraden af en opgave estimeres normalt i enheder kaldet Story Points. De er relative. Og hvert udviklingsteam arbejder i praksis med at fastsætte Story Point-værdien baseret på tidligere erfaring.
I separate artikler har vi dækket mere om udviklingsteamets hastighed og hvordan man måler den.
S for Lille
En User Story, der er accepteret til realisering af udviklingsteamet, skal være kortfattet. Det vil sige, den bør ikke være længere end én Sprint. Hvis udviklerne opdager under Sprint-planlægningen, at den User Story, der er foreslået af Product Owner, er for lang, bør de opdele den i muligvis uafhængige dele.
T for Testbar
Det sidste bogstav i akronymet INVEST står for testbar. Det betyder, at produktændringen beskrevet i User Story skal holde vand og være verificerbar. Med andre ord bør det være muligt at verificere, om den løsning, der er implementeret af udviklerne, har givet den antagne værdi til en bestemt interessent.
Oprettelse af den bedste User Story – sammendrag
INVEST er et akronym, der beskriver en veludført User Story. Den bør være:
- Uafhængig af andre User Stories. Så den kan ændres eller fjernes fra produktbackloggen, hvis behovet opstår.
- Forhandlingsbar. Den bør specificere, hvad der skal gøres, mens valget af, hvordan det skal gøres, overlades til udviklerne.
- Værdifuld, dvs. retfærdiggøre forretningssansen ved at ændre produktet. Eller Vertikal, dvs. præsentere en ny funktionalitet af produktet, der er synlig for brugeren.
- Estimerbar, hvilket betyder at have en definerbar størrelse og færdiggørelseskriterium.
- Lille nok til at kunne fuldføres i én Sprint.
- Testbar så det med sikkerhed kan bestemmes, at det er blevet implementeret.
Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Som projektleder er Caroline en ekspert i at finde nye metoder til at designe de bedste arbejdsgange og optimere processer. Hendes organisatoriske færdigheder og evne til at arbejde under tidspres gør hende til den bedste person til at gøre komplicerede projekter til virkelighed.
Scrum Guide:
- Ordbog over grundlæggende termer, roller og begreber
- Hvad er Scrum?
- Scrum værdier
- Hvordan implementerer man Scrum i din virksomhed?
- Scrum Team - hvad er det, og hvordan fungerer det?
- Hvem er en Product Owner?
- De mest almindelige fejl hos Product Owner
- Hvem er Scrum Masteren?
- De mest almindelige fejl hos Scrum Master
- Hvilke statistikker og målinger bør Scrum Masteren følge?
- Udviklingsteam i Scrum
- De mest almindelige fejl hos udviklere
- Scrum artefakter
- Skalering af Scrum
- Sprint Backlog
- Hvad er produktbackloggen?
- Hvad er brugerhistorier?
- At skabe den bedste User Story med INVEST
- De mest almindelige fejl i User Stories
- Brugerhistorie Acceptkriterier
- Estimering og Story Points i Scrum
- Planlægningspoker
- Team Estimeringsspil
- Definere inkrement
- Scrum begivenheder
- Hvad er et Burndown-diagram?
- Fordele og ulemper ved burndown-diagrammet
- Kanban-tavler i Scrum og Scrumban
- Hastighed i Scrum - Udviklingsteamets hastighed
- Daglig Scrum
- Sprintplanlægning
- Sprintgennemgang
- Hvad er en Sprint Retrospektiv?
- Almindelige fejl under en Sprint Retrospektiv
- Produkt Backlog pleje
- Hvordan opretter og fortolker man et burndown-diagram?