Estimating User Stories
Når vi udvikler software, har vi ofte brug for at vurdere, hvor stort et stykke arbejde en user story repræsenterer. Det kalder vi estimering.
Et estimat er ikke et løfte om, præcis hvor lang tid arbejdet tager. Det er vores bedste vurdering ud fra den viden, vi har på det tidspunkt.
Estimering kan hjælpe teamet med at:
- forstå hvor stort et stykke arbejde en User Story repræsenterer
- sammenligne forskellige User Stories
- planlægge og prioritere arbejdet
- opdage usikkerheder og manglende krav
- skabe en fælles forståelse af opgaven
Det sidste punkt er vigtigt. Hvis to udviklere vurderer den samme user story meget forskelligt, kan det være tegn på, at de ikke har den samme forståelse af opgaven.
Det kan være svært at svare på:
“Hvor mange timer tager denne user story?”
Det er ofte lettere at svare på:
“Er denne user story større eller mindre end en User Story, vi allerede kender?”
Derfor anvendes ofte relativ estimering.
Et team kan fx have en kendt user story, som er vurderet til 3 story points. Nye user stories vurderes i forhold til denne.
Story points kan afspejle en kombination af:
- arbejdsmængde – hvor meget skal der laves?
- kompleksitet – hvor svært er arbejdet?
- usikkerhed – hvor godt forstår vi opgaven og løsningen?
Hvis en user story vurderes til 5 story points, betyder det ikke, at den tager 5 timer.
Hvis:
- User story A = 3 Story points
- User story B = 8 Story points
betyder det, at teamet vurderer B til at være væsentligt større, mere kompleks og/eller mere usikker end A.
Planning Poker er en teknik til at estimere user stories i fællesskab.
Der anvendes typisk en skala som:
1 – 2 – 3 – 5 – 8 – 13 – 21
Springene mellem tallene bliver større, fordi usikkerheden normalt bliver større, jo større en opgave er.
Det giver fx ikke meget mening at diskutere, om en stor og usikker user story er 18 eller 19 story points.
- Teamet læser user story og acceptkriterierne
- Teamet stiller spørgsmål og afklarer user story’en.
- Hvert teammedlem vælger individuelt et story point-estimat.
- Alle viser deres estimat samtidig.
- Hvis estimaterne er forskellige, diskuterer teamet hvorfor.
- Især det højeste og laveste estimat forklares.
- Teamet estimerer igen.
- Processen fortsætter, indtil teamet har opnået en rimelig fælles forståelse.
Fire udviklere estimerer:
3 | 5 | 5 | 13
Teamet skal ikke bare tage gennemsnittet.
Spørg i stedet:
Hvorfor vurderer én udvikler user story’en til 3 og en anden til 13?
Personen, der valgte 13, siger måske:
“Jeg tror, vi skal hente oplysninger fra tre forskellige tabeller. Har I andre tænkt på det?”
Nu har Planning Poker afdækket noget, som resten af teamet måske havde overset.
Samtalen om estimatet kan derfor være vigtigere end selve tallet.
For at kunne forstå og estimere en user story kan det være nyttigt at overveje, hvilket arbejde der skal udføres.
En user story beskriver brugerens behov:
Som underviser vil jeg kunne registrere kørsel for praktikbesøg, så jeg kan få kørselsgodtgørelse.
Acceptkriterierne præciserer, hvornår behovet er opfyldt:
- Givet at jeg er logget ind, når jeg registrerer dato, destination og antal kørte kilometer, så bliver køreturen gemt.
Teamet kan derefter nedbryde user story’en i tasks.
Eksempel:
- Opret køretur
- Gem køretur i databasen
- Test oprettelse af køretur
Tasks gør det konkrete arbejde synligt.
En task skal ikke beskrive hver enkelt programmeringshandling.
Dette er normalt for detaljeret til at være selvstændige tasks:
- Skriv en SQL
INSERT - Opret et
Trip-objekt - Lav et
if-statement - Kald
executeUpdate() - Lav et
for-loop
Det er implementeringsdetaljer, som kan være en del af arbejdet med en task.
Et nyttigt spørgsmål er:
Giver dette mening som et selvstændigt og afgrænset stykke arbejde?
En task skal være lille nok til at være overskuelig, men stor nok til at være meningsfuld at følge.
Der findes ikke altid ét korrekt svar på, hvordan en user story skal nedbrydes.
Forestil jer denne user story:
Som bruger vil jeg kunne gemme opskrifter som favoritter, så jeg hurtigt kan finde dem igen
Ved første øjekast virker den måske lille.
Når teamet diskuterer arbejdet, opdager de måske, at:
- favoritten skal knyttes til den korrekte bruger
- favoritter skal gemmes permanent
- brugerens favoritter skal kunne vises
- en favorit skal kunne fjernes
- det er uklart hvad hurtigt betyder
- funktionaliteten skal testes
Teamet opdager altså arbejde ved at undersøge og nedbryde user story’en.
Det kan føre til et andet og bedre begrundet estimat.
Formålet er ikke at designe hele løsningen ned til mindste detalje, før en user story kan estimeres.
Teamet skal forstå user story’en godt nok til at kunne foretage et rimeligt estimat.
Nedbrydning i tasks kan bruges til at:
- forstå omfanget
- opdage skjult arbejde
- identificere usikkerhed
- skabe fælles forståelse
Den mere detaljerede task-nedbrydning kan fortsætte, når teamet skal i gang med arbejdet.
En stor user story kunne være:
Som boligsøgende vil jeg kunne søge efter boliger baseret på størrelse, antal rum, boligtype, pris, alder og faciliteter.
Man kan overveje at dele den op i flere mindre user stories.
- Søge på størrelse og antal rum
- Tilføj boligtype og pris
- Tilføj alder og faciliteter
Hver mindre story gør søgefunktionen mere avanceret. Den første version er simpel med kun et par søgekriterier. Men den kan have kundeværdi, selv med få kriterier.
User story
→ Hvad vil brugeren opnå?
Acceptkriterier
→ Hvornår er brugerens behov opfyldt?
Tasks
→ Hvilket arbejde skal teamet udføre?
Estimering
→ Hvor stort, komplekst og usikkert vurderer vi arbejdet til at være?
Planning Poker
→ Har vi den samme forståelse af user story’en?
- Et estimat er en vurdering – ikke et løfte.
- Story points er relative – de er ikke timer.
- Nedbrydning kan afdække skjult arbejde og usikkerhed.
- Uenighed i Planning Poker er nyttig, fordi den kan afsløre forskellig forståelse af opgaven.