Når de jobber med et Agile-prosjekt, planlegger teamet arbeidet for kommende spurter ved å lage historier. En historie definerer en enkelt funksjonalitet-innkapslet aktivitet med beskrivelse og akseptkriterier.
Sprintene varer vanligvis fra to til fire uker. I løpet av den tiden må teamet forstå hvor mye innhold de kan ta inn i en sprint, slik at de fortsatt kan klare det innenfor den gitte sprinttiden.
På et ikke-smidig prosjekt vil du anslå arbeidet vanligvis i dagsverk. Det betyr hvor mange heltidsansatte trenger du for å fullføre denne aktiviteten? I så fall tenker du alltid på dagene og antallet personer når du lager estimater.
På et smidig prosjekt er ting annerledes. Du teller ikke lenger dager eller personer for å beregne det endelige anslaget. Faktisk skal vi forby selv å beregne innsatsen i noe sånt som mannsdager. I stedet lar du teamet konvertere til én generelt akseptert verdi for historien som vil representere det samlede anslaget.
Nå for hva nøyaktig verdien er, spiller dette ingen rolle. Riktignok er den vanligste representanten for historieestimater historiepoengene. Disse er i utgangspunktet Fibonacci-tall som starter fra 0, 1, 2, 3, 5, 8, 13, 21 osv. Den neste verdien er summen av de to foregående tallene. Dette vil bidra til å skille historiens generelle kompleksitet, ettersom hvert neste høyere tall er betydelig høyere enn det forrige.
Men du trenger ikke holde deg til historiepoeng. Det kan være anslag på T-skjortestørrelse (XXS, XS, S, M, L, XL, XXL). Hvis du ønsker å være veldig kreativ, kan du introdusere ZOO-dyr og bruke dem til å beregne størrelse.
Uansett handler det nå mye mer om hele teamets følelse av hvilket tall (eller dyr) som best representerer den generelle kompleksiteten til denne spesielle historien. Det handler definitivt ikke om tidsrepresentasjon. Til slutt skal laget fullføre hver historie som er tatt inn i spurten innenfor den spurten. Så tiden er allerede gitt i begynnelsen og er et konstant tall.
Innholdsfortegnelse
Komponenter av Story Points Estimat
En historiepoengvurdering handler absolutt ikke bare om hvor kompleks/vanskelig en bestemt historie er. Når man estimerer en historie, bør teamet vurdere flere aspekter og reflektere dem i den endelige estimeringsverdien.
Det endelige estimatet er da en verdi som representerer en kombinasjon av alle aspekter dannet til et enkelt tall. Her er hva et slikt estimat skal inkludere.
#1. Teknisk vanskelighetsgrad
Forutsatt at vi estimerer historier for et utviklingsteam, vil den tekniske vanskeligheten til historien være et av de første områdene teamet vil konsentrere seg om som standard.
Og dette er for all del den riktige tilnærmingen. Teamet fullt av tekniske eksperter burde vite best hvordan man vurderer et slikt område av en historie. Her kan teamet vurdere ulike tilnærminger eller hint, som:
- Hvordan er denne historien sammenlignet med andre som allerede er levert fra synet på teknisk kompleksitet?
- Hvor mange kodefiler må teamet opprette/oppdatere for å fullføre historien?
- Hvor mange ekstra kodeendringer vil denne historien generere til de omkringliggende systemprosessene?
- Hvor kompleks vil algoritmen eller prosesslogikken være å implementere?
#2. Eksterne avhengigheter og risikoer
Man ville bli overrasket, men oftere enn ikke er suksessen til historiene inne i lagets sprint avhengig av bidrag fra andre lag eller personer utenfor laget selv.
Historier der alt teamet kan utrette på egen hånd er det enkleste å anslå. Ting blir komplisert hvis teamet trenger ekstern hjelp til historiene sine. For personer utenfor teamet vil denne aktiviteten naturligvis ikke være en prioritet. Teamet må bare stole på den faktoren og vurdere den innenfor estimeringen.
Hvor mye denne faktoren vil øke det totale estimatet vil mest avhenge av teamets tidligere erfaring og «nivået av eksternalitet». Vanligvis, i noen spurter, vil teamet etablere en naturlig enhetlig følelse for hvor mye denne avhengigheten av eksterne mennesker kan komplisere en vellykket fullføring av historien.
#3. Gjenbruksfaktor
Det neste området å vurdere er hvor mye av det eksisterende innholdet teamet kan gjenbruke for å fullføre historien. Selvfølgelig, hvis noen av delene allerede er til stede på en eller annen måte, er det ikke nødvendig å bygge det fra bunnen av. I stedet kan teamet gjenbruke den allerede opprettede løsningen for å bygge en ny mye raskere.
På en slik måte kan denne kunnskapen senke det totale estimatet, selv om historien normalt (uten denne gjenbrukbarheten) ville være mer kompleks basert på det definerte innholdet.
#4. Forståelse av eget lag
En bemerkelsesverdig faktor som ingen dagsverksbasert estimat noen gang kan vurdere, er selvkunnskapen om lagets ansiennitet og kapasitet.
Ettersom teamet jobber sammen og leverer flere spurter, vil folk på innsiden bli kjent med hverandre. De vil begynne å forstå hvem som vet hva og hvor god hun/han er til det. Og når alle kjenner resten av teamet, kan de sammen som et team vurdere dette under estimeringen.
Hvis historien er tung på noen konkrete tekniske ferdigheter og den ferdigheten er veldig sterkt tilstede i teamet, er det tydelig at historien ikke vil være så mye problem. Eller omvendt, hvis den nødvendige ferdigheten mangler i hele teamet, vil teamet trenge betydelig mer tid for å komme inn i emnet, og de skal reflektere det i estimatet.
Anslå historien
Hver historieestimering bør være en laginnsats. Ingen enkeltstemme skal forhåndsdefinere historiens kompleksitet. Det endelige målet bør være å la teamet diskutere estimatet til alle medlemmene er enige om én enkelt verdi som vil representere det endelige estimatet.
Teamet kan gjøre estimeringen direkte under sprintavgrensningsdiskusjonen (et møte der historiene blir diskutert og avklart mellom teamet), eller alternativt kan de reservere en dedikert tid til å gjøre nettopp det.
Eksempel på estimeringsprosess
Sprintplanforpliktelse
Teamet har nå et etterslep med historier som allerede har gått gjennom estimeringsøktene. Ideelt sett har historiene blitt tildelt (bortsett fra den endelige estimatverdien) også en prioritet slik at teamet vet hvilke historier som kommer neste gang i neste sprint.
Her kommer planleggingsøkten, hvor teamet skal plukke ut noen av historiene til neste sprint. Beslutningen om hvilke historier du skal velge, bør være basert på følgende:
✅ Historier med de høyeste prioriteringene teamet vurderer først.
✅ En opplevelse av teamet av hvor mange historiepoeng de klarer å fullføre i løpet av en sprint. Denne kunnskapen kommer bare med tiden og erfaringen til teamet. Du trenger flere spurter for å finjustere og få en skikkelig forståelse av denne evnen.
✅ Du bør ikke bare vurdere det totale antall historiepoeng og prioritet. En annen vurdering er hvordan ferdighetene i teamet vil spre seg på utvalgte historier. For eksempel, hvis teamet bare har to frontend-utviklere, velger de kanskje ikke bare historier som kun består av frontend-utvikling. Det ville føre til overutnyttelse av de to gutta mens resten av laget ikke er så mye. Så kunnskapen til teamet kommer hånd i hånd med effektiviteten av sprintinnhold.
Hastighetsfaktor
Fremfor alt sitter hastigheten til laget (for den kommende spurten). Dette tallet er ikke relatert til det totale antallet historiepoeng på noen måte. Det indikerer imidlertid hvor mye laget vil være tilgjengelig for arbeid for den kommende spurten.
For å kunne planlegge innholdet for en sprint nøyaktig, setter vi begge aspektene sammen:
Det tar tid og øvelse å finne sweet spot.
Fordeler og vanlige feil
Det er overraskende hvor mye teamene er villige til å komplisere for seg selv prosessen underveis i transformasjonen til et smidig team. Det føles bokstavelig talt som om du trenger å «få det» før du kan begynne å jobbe i den modusen.
Dette første trinnet er dessverre også det vanskeligste. I noen tilfeller tar det jevne år, spesielt i strengt konservative bedriftsmiljøer, hvor tiden alene setter seg fast i tid.
Uansett, dette er hva som vil skje når teamet «får det»:
- Du trenger ikke lenger å beregne personer eller dager for å vite når noe kan fullføres.
- Teamet vil lære å lage historier bare så komplekse slik at de passer inn i en sprint. Hvis en historie er mer kompleks, blir den automatisk delt opp i flere historier.
- Teamet har gode estimater for hvert stykke arbeid, og når de først planlegger det for en sprint, vet du nøyaktig når det er termin.
- Det vil øke påliteligheten og forutsigbarheten til laget.
- Alle personer i teamet vil være «på samme frekvens». De vil se på en historie og vil forstå lignende ting. Kanskje etter en tid gidder de ikke engang å anslå. De ser tallet i hodet, og siden alle ser det samme tallet, kan de forplikte seg til historier i en sprint selv uten dette eksplisitte anslaget.
Og dette er hva som vanligvis skjer hvis teamet fortsatt ikke er i stand til å forstå prosessen eller måten å jobbe på:
- De holder seg på en eller annen måte fortsatt til anslagene fra gammeldagse. De konverterer alt til dager eller personer involvert. Historiepoeng eller Fibonacci-tall betyr antall dager, enten direkte eller indirekte, via ulike transformasjoner.
- Lederskap sammenligner lagene basert på antall historiepoeng levert hver sprint. Dette er så mye feil som det kan bli. Et vesentlig faktum er da ikke forstått: Hvert lag anslår historiepoengene annerledes. Det er absolutt ingen grunn til å gjøre en innsats for å synkronisere to team for å estimere historiene deres på «samme måte».
- Mens et lags historiepoeng betyr å tegne en sirkel, for et annet lag kan det bety å tegne et hus med flatt tak, fire vinduer og to dører. Og det er helt greit.
- Noen ganger har lagene en tendens til å anslå nesten alt mellom to til fire forskjellige tall. Kanskje fordi de frykter at en historie har tallet 123, vil noen tro at det har noe med antall dager å gjøre. Men faktum er at Fibonacci-skalaen har en uendelig mengde tall. Vi trenger ikke begrense oss til anslag på 3, 5 eller 8. Vi kan sikkert (og kanskje vi lager historiene allerede med det formålet i tankene for å være så komplekse, i så fall er dette greit), men vi trenger absolutt ikke.
- Estimering er drevet av seniorpersoner som vil forhåndsdefinere forventningene til hele gruppen. Vi bør aldri tillate å påvirke estimatet av ett teammedlem. Alle har lik rett til å si sin mening og bli lyttet til.
Siste ord
Det er ikke alltid lett å bytte til smidig estimering fra de mer tradisjonelle tilnærmingene – både for teamene og ledelsen ovenfor. For å få det til å fungere, må begge sider forstå prosessen. Hvis en av dem ikke forstår, er overgangsperioden en vanskelig vei full av motstridende forventninger.
Men når alt forvandles, vil noen magiske ting begynne å skje. Teamene vil bedre kunne estimere og planlegge arbeidet sitt, og ledelsen vil ha mer forutsigbare utgivelser og veikart å stole på.
Deretter kan du sjekke ut usunne prosesser som kan ødelegge spurten din.