I et smidig prosjekt, forbereder teamet seg på kommende sprinter ved å definere oppgaver gjennom brukerhistorier. En brukerhistorie beskriver en spesifikk funksjonalitet, inkludert en beskrivelse og akseptkriterier.
Sprintene varer vanligvis mellom to og fire uker. I løpet av denne perioden må teamet vurdere hvor mye arbeid de kan håndtere, for å sikre at de kan fullføre alle oppgaver innenfor tidsrammen for sprinten.
I et tradisjonelt prosjekt vil man typisk estimere arbeid i dagsverk. Dette innebærer å beregne hvor mange personer som trengs på heltid for å fullføre en oppgave. Estimeringen vil da fokusere på antall dager og ressurser.
I smidige prosjekter er tilnærmingen annerledes. Her teller man ikke antall dager eller personer for å beregne estimater. Faktisk bør man unngå å vurdere innsatsen i form av mannsdager. Istedenfor lar man teamet benytte en felles enhet for å representere den samlede størrelsen på historien.
Hvilken enhet man velger er ikke avgjørende, men den mest brukte er historiepoeng. Disse er basert på Fibonacci-tallsekvensen, som starter med 0, 1, 2, 3, 5, 8, 13, 21, osv. Hvert påfølgende tall er summen av de to foregående. Dette gjør det lettere å skille mellom kompleksiteten av historiene, da hvert høyere tall er betydelig større enn det forrige.
Man trenger ikke holde seg til historiepoeng. Man kan også bruke T-skjortestørrelser (XXS, XS, S, M, L, XL, XXL) eller, for å være mer kreativ, dyrenavn fra en dyrehage.
Det sentrale er at hele teamet har en felles forståelse av hvilket tall (eller dyr) som best representerer den totale kompleksiteten til en gitt historie. Det handler ikke om tidsestimering, da tidsrammen for en sprint er en konstant. Teamet skal fullføre alle historiene som er med i sprinten innenfor den angitte perioden.
Komponenter i et historiepoengestimat
Et historiepoengestimat handler om mer enn bare kompleksiteten til en historie. Teamet må vurdere flere faktorer som påvirker estimatet.
Det endelige estimatet skal være en enkelt verdi som representerer kombinasjonen av disse aspektene. Her er de viktigste faktorene som bør tas med i vurderingen:
#1. Teknisk Vanskelighetsgrad
Når utviklingsteamet estimerer historier, vil den tekniske vanskelighetsgraden være en av de første aspektene de ser på.
Dette er en naturlig tilnærming, da tekniske eksperter er best egnet til å vurdere denne delen av historien. Teamet kan vurdere følgende:
- Hvordan sammenligner denne historien seg med andre som allerede er fullført med tanke på teknisk kompleksitet?
- Hvor mange kodefiler må opprettes/oppdateres for å fullføre historien?
- Hvor mange ekstra kodeendringer vil denne historien generere i relaterte systemer?
- Hvor kompleks vil algoritmen eller prosesslogikken være å implementere?
#2. Eksterne Avhengigheter og Risiko
Det er ikke uvanlig at teamet er avhengig av andre team eller personer utenfor sitt eget team for å fullføre historier.
Historier som teamet kan fullføre på egenhånd er enklere å estimere. Situasjonen blir mer komplisert når teamet er avhengig av ekstern hjelp, da denne aktiviteten sannsynligvis ikke vil være prioritert for de involverte eksterne ressurser. Teamet må derfor ta hensyn til denne usikkerheten i sitt estimat.
Hvor mye denne faktoren påvirker estimatet avhenger av teamets tidligere erfaring og graden av ekstern avhengighet. Over tid vil teamet utvikle en felles forståelse for hvor mye eksterne avhengigheter kan komplisere fullføringen av en historie.
#3. Gjenbruksfaktor
Neste faktor er hvor mye av eksisterende innhold teamet kan gjenbruke for å fullføre historien. Hvis deler av løsningen allerede finnes, trenger man ikke å bygge alt fra bunnen av, og teamet kan bruke eksisterende løsninger til å raskere utvikle nye.
Dette kan redusere estimatet betydelig, selv om historien i utgangspunktet ville være mer kompleks uten gjenbruksmuligheter.
#4. Teamets Egenforståelse
En faktor som tradisjonell dagsverksbasert estimering ikke tar høyde for, er teamets sammensetning, erfaring og kapasitet.
Etter hvert som teamet jobber sammen og leverer flere sprinter, lærer medlemmene hverandres styrker og svakheter. Når alle kjenner de andre teammedlemmene, kan de bruke denne kunnskapen i estimeringsprosessen.
Hvis en historie krever spesielle tekniske ferdigheter som er sterkt representert i teamet, vil historien være enklere å håndtere. Omvendt, hvis teamet mangler den nødvendige kompetansen, må de sette av mer tid til læring, noe som bør reflekteres i estimatet.
Estimering av Historien
Hver historieestimering bør være et resultat av en felles innsats. Ingen enkeltperson skal forhåndsbestemme historiens kompleksitet. Målet er at teamet diskuterer estimatet til alle er enige om én felles verdi.
Estimeringen kan gjennomføres under sprintplanleggingsmøtet, hvor historiene diskuteres og avklares, eller teamet kan sette av en dedikert tid kun for estimering.
Eksempel på Estimeringsprosess
| 1. Velg et estimeringsverktøy, for eksempel Planning Poker, Miro-tavle eller lignende. | |
| 2. Legg frem en historie. Teamet diskuterer eventuelle spørsmål eller kommentarer til historien, slik at alle er godt informert. | |
| 3. Start estimeringen. Alle teammedlemmer velger et tall fra Fibonacci-sekvensen. | |
| 4. Sammenlign resultatene og diskuter. Vanligvis vil det være forskjeller mellom to eller tre tall. Medlemmer som har valgt de laveste tallene begrunner hvorfor, mens de som har valgt de høyeste tallene også begrunner sitt valg. Målet er å legge frem alle argumenter og vurderinger slik at hele teamet har en felles forståelse av historiens kompleksitet. | |
| 5. Etter diskusjonen estimerer teamet igjen. Ofte vil alle konvergere mot ett eller to tall. Diskusjonen gjentas. Enten kommer man til enighet, eller man gjør en ny runde med estimering. | |
| 6. Estimeringen er først ferdig når alle teammedlemmene er helt enige om det endelige estimatet. Det skal være enighet i hele teamet, ikke bare blant noen få individer. Det er viktig at alle forstår historiens kompleksitet, da enhver i teamet kan potensielt bli tildelt historien senere. |
Forpliktelse til Sprintplanen
Etter estimeringsprosessen har teamet en liste med historier som har et estimat og en prioritering. Det er denne listen som utgjør grunnlaget for neste sprint.
Valg av hvilke historier som skal inkluderes i sprinten, bør baseres på følgende:
- ✅ Prioriter historier med høyest prioritet.
- ✅ Baser utvalget på hvor mange historiepoeng teamet vanligvis klarer å fullføre i løpet av en sprint. Denne kunnskapen bygges opp over tid og med erfaring.
- ✅ Vurder fordelingen av nødvendige ferdigheter for å unngå overbelastning av enkeltpersoner. Hvis teamet for eksempel har få front-end-utviklere, bør man unngå å velge bare historier med front-end-utvikling.
Hastighetsfaktor
Teamets hastighet, som representerer hvor mye arbeid teamet kan utføre i en gitt sprint, er en viktig faktor. Den er ikke direkte knyttet til det totale antall historiepoeng, men indikerer teamets tilgjengelighet for arbeid i den kommende sprinten.
For å planlegge innholdet i en sprint nøyaktig, kombineres følgende aspekter:
- Lagets hastighet: Målt i dager. En dags tilgjengelighet tilsvarer 1 i lagets hastighet. Et lag på 10, fullt tilgjengelige i en sprint på 2 uker, har for eksempel en kapasitet på 100.
- Vanlig mengde historiepoeng fullført per sprint: Målt i historiepoeng. Dette tallet kommer fra tidligere erfaring og er nært knyttet til teamets hastighet.
Det krever tid og erfaring for å finne den optimale balansen.
Fordeler og Vanlige Feil
Overgangen til smidig estimering kan være vanskelig og kompleks. Det krever en endring i tankesett før man kan jobbe effektivt i denne modellen.
Det første steget er ofte det vanskeligste, og for noen kan det ta tid, spesielt i konservative organisasjoner hvor tid ofte er fastlåst i tradisjonell tenkning.
Her er hva som skjer når teamet «får det til»:
- Det er ikke lenger nødvendig å beregne antall personer eller dager for å vite når noe kan fullføres.
- Teamet vil lære å dele opp store oppgaver slik at hver del passer innenfor en sprint.
- Teamet vil ha gode estimater for hver oppgave, noe som fører til mer forutsigbarhet.
- Det vil øke påliteligheten og forutsigbarheten til teamet.
- Alle i teamet vil være «på samme frekvens». De ser på en historie og har en felles forståelse. Etterhvert kan estimeringen bli overflødig, da teamet har utviklet en felles intuisjon.
Dette er hva som vanligvis skjer hvis teamet ikke forstår prosessen:
- Teamet holder fast ved gammeldagse metoder og konverterer alt til dager eller antall personer. Historiepoeng og Fibonacci-tall tolkes som antall dager, direkte eller indirekte.
- Ledelsen sammenligner team basert på antall historiepoeng levert per sprint. Dette er en misforståelse, da hvert team estimerer historiepoeng på ulike måter. Det er ingen grunn til å synkronisere team for å estimere på «samme måte».
- Mens en historiepoeng for et team betyr å tegne en sirkel, kan det bety å tegne et hus for et annet. Og dette er helt akseptabelt.
- Teamet har en tendens til å anslå de fleste oppgaver mellom to til fire tall, kanskje i frykt for at høye tall vil tolkes som antall dager. Fibonacci-sekvensen har en uendelig mengde tall. Vi trenger ikke begrense oss til 3, 5 eller 8.
- Estimeringen styres av seniorpersoner som forhåndsdefinerer forventningene til gruppen. Det er viktig å unngå at en enkeltperson påvirker estimeringen. Alle har rett til å ytre sin mening og bli hørt.
Siste Ord
Overgangen til smidig estimering kan være utfordrende, både for team og ledelse. For å lykkes må begge parter forstå prosessen. Hvis en av dem ikke forstår, kan overgangsperioden bli vanskelig og konfliktfylt.
Men når overgangen er gjennomført, vil teamene kunne estimere og planlegge arbeidet sitt bedre, og ledelsen vil ha mer forutsigbare leveranser og veikart å forholde seg til.
Du kan deretter se på usunne prosesser som kan ødelegge sprinten din.