Når de arbejder på et Agile-projekt, planlægger teamet arbejdet for kommende sprints ved at skabe historier. En historie definerer en enkelt funktionalitetsindkapslet aktivitet med beskrivelse og acceptkriterier.
Sprintene varer typisk fra to til fire uger. Inden for den tid skal teamet forstå, hvor meget indhold de kan tage i en sprint, så de stadig kan klare det inden for den givne sprinttid.
På et ikke-agilt projekt vil du estimere arbejdet normalt i manddage. Det betyder, hvor mange fuldtidsansatte skal du bruge for at gennemføre denne aktivitet? I så fald tænker du altid på dagene og antallet af personer, når du laver estimater.
På et agilt projekt er tingene anderledes. Du tæller ikke længere dage eller personer til at beregne det endelige skøn. Faktisk vil vi forbyde selv at beregne indsatsen i noget som mandedage. I stedet lader du teamet konvertere til én generelt accepteret værdi for historien, som vil repræsentere det overordnede skøn.
Hvad nu værdien er, betyder det ikke rigtig noget. Sandt nok er den mest almindelige repræsentant for historieestimater Story Points. Det er grundlæggende Fibonacci-tal, der starter fra 0, 1, 2, 3, 5, 8, 13, 21 osv. Den næste værdi er summen af de to foregående tal. Dette vil hjælpe med at differentiere historiens overordnede kompleksitet, da hvert næste højere tal er væsentligt højere end det foregående.
Men du behøver ikke holde dig til historiepunkter. Det kan være t-shirtstørrelsesvurderinger (XXS, XS, S, M, L, XL, XXL). Hvis du gerne vil være rigtig kreativ, kan du introducere ZOO-dyr og bruge dem til størrelsesvurdering.
Uanset hvad, så handler det nu meget mere om hele holdets følelse af, hvilket tal (eller dyr) der bedst repræsenterer den overordnede kompleksitet af denne særlige historie. Det handler bestemt ikke om tidsrepræsentation. I sidste ende skal holdet færdiggøre hver historie, der tages ind i spurten inden for den sprint. Så tiden er allerede givet i begyndelsen og er et konstant tal.
Indholdsfortegnelse
Komponenter af Story Points Estimat
Et story point estimering handler absolut ikke kun om, hvor kompleks/svær en bestemt historie er. Når man estimerer en historie, bør teamet overveje flere aspekter og afspejle dem i den endelige estimeringsværdi.
Det endelige skøn er så en værdi, der repræsenterer en kombination af alle aspekter dannet til et enkelt tal. Her er, hvad et sådant skøn skal omfatte.
#1. Teknisk vanskelighed
Hvis vi antager, at vi estimerer historier for et udviklingsteam, vil historiens tekniske sværhedsgrad være et af de første områder, som teamet som standard vil koncentrere sig om.
Og det er i hvert fald den rigtige tilgang. Holdet fyldt med tekniske eksperter burde bedst vide, hvordan man vurderer et sådant område af en historie. Her kan teamet overveje forskellige tilgange eller hints, som:
- Hvordan er denne historie sammenlignet med andre, der allerede er leveret ud fra en teknisk kompleksitet?
- Hvor mange kodefiler skal teamet oprette/opdatere for at færdiggøre historien?
- Hvor mange ekstra kodeændringer vil denne historie generere til de omkringliggende systemprocesser?
- Hvor kompleks vil algoritmen eller proceslogikken være at implementere?
#2. Eksterne afhængigheder og risici
Man ville blive overrasket, men som oftest afhænger historiernes succes inde i holdets sprint af bidrag fra andre hold eller personer uden for holdet selv.
Historier, hvor alt, hvad teamet kan udrette på egen hånd, er det nemmeste at vurdere. Tingene bliver komplicerede, hvis teamet har brug for ekstern hjælp til deres historier. For folk uden for holdet vil denne aktivitet naturligvis ikke være en prioritet. Holdet skal bare regne med den faktor og overveje det inden for vurderingen.
Hvor meget denne faktor vil øge det samlede estimat vil mest afhænge af teamets tidligere erfaring og “eksternalitetsniveauet”. Normalt, i nogle sprints, vil holdet etablere en naturlig forenet følelse af, hvor meget denne afhængighed af eksterne mennesker kan komplicere en vellykket afslutning af historien.
#3. Genbrugsfaktor
Det næste område at overveje er, hvor meget af det eksisterende indhold teamet kan genbruge for at fuldende historien. Det er klart, at hvis nogle af delene allerede er til stede på den ene eller anden måde, er det ikke nødvendigt at bygge det fra bunden. Teamet kan snarere genbruge den allerede oprettede løsning til at bygge en ny meget hurtigere.
På en sådan måde kan denne viden sænke det samlede skøn, selvom historien normalt (uden denne genanvendelighed) ville være mere kompleks baseret på det definerede indhold.
#4. Forståelse af eget team
En bemærkelsesværdig faktor, som intet mandagebaseret estimat nogensinde kan overveje, er selverkendelsen af holdets anciennitet og kapacitet.
Da holdet arbejder sammen og leverer adskillige spurter, vil folk indeni lære hinanden at kende. De vil begynde at forstå, hvem der ved hvad og hvor god hun/han er til det. Og når alle kender resten af holdet, kan de sammen som et team overveje dette under estimeringen.
Hvis historien er tung på nogle konkrete tekniske færdigheder, og den færdighed er meget stærkt til stede i teamet, er det den klare erkendelse af historien, der ikke vil være så meget besvær. Eller omvendt, hvis de nødvendige færdigheder mangler inden for hele teamet, så vil teamet bruge betydeligt mere tid til at komme ind på emnet, og de skal afspejle det i estimatet.
Vurdering af historien
Hver historievurdering bør være en teamindsats. Ingen enkelt stemme bør foruddefinere historiens kompleksitet. Det endelige mål bør være at lade teamet diskutere estimatet, indtil alle medlemmer er enige om en enkelt værdi, der repræsenterer det endelige skøn.
Holdet kan foretage estimeringen direkte under sprintforfiningsdiskussionen (et møde, hvor historierne bliver diskuteret og afklaret mellem holdet), eller alternativt kan de reservere en dedikeret tid til netop dette.
Eksempel på estimeringsproces
Sprint Plan Commitment
Holdet har nu et efterslæb med historier, der allerede har været igennem estimeringssessionerne. Ideelt set har historierne (bortset fra den endelige skønsværdi) også fået en prioritet, så holdet ved, hvilke historier der kommer næste gang i næste sprint.
Her kommer planlægningssessionen, hvor holdet skal vælge nogle af historierne til næste sprint. Beslutningen om, hvilke historier der skal vælges, skal baseres på følgende:
✅ Historier med de højeste prioriteter, som teamet overvejer først.
✅ Teamets oplevelse af, hvor mange historiepoint de er i stand til at afslutte inden for en sprint. Denne viden kommer kun med holdets tid og erfaring. Du har brug for flere spurter for at finjustere og få en ordentlig forståelse af denne evne.
✅ Du bør ikke kun overveje det samlede antal historiepoint og prioritet. En anden overvejelse er, hvordan færdighederne inde i teamet vil sprede sig på udvalgte historier. For eksempel, hvis teamet kun har to frontend-udviklere, vælger de måske ikke kun historier, der kun består af frontend-udvikling. Det ville føre til overudnyttelse af de to fyre, mens resten af holdet ikke er så meget. Så holdets viden kommer hånd i hånd med effektiviteten af sprintindholdsskabelse.
Hastighedsfaktor
Frem for alt sidder holdets hastighed (til den kommende sprint). Dette tal er ikke relateret til det samlede antal historiepoint på nogen måde. Det indikerer dog, hvor meget holdet vil være til rådighed for arbejde til den kommende sprint.
For præcist at kunne planlægge indholdet til en sprint, sætter vi begge aspekter sammen:
Det tager tid og øvelse at finde det søde sted.
Fordele og almindelige fejl
Det er overraskende, hvor meget teamene er villige til at komplicere for sig selv processen undervejs i transformationen til et agilt team. Det føles bogstaveligt talt som om du skal “få det”, før du kan begynde at arbejde i den tilstand.
Dette første skridt er desværre også det sværeste. I nogle tilfælde tager det lige år, især i strengt konservative virksomhedsmiljøer, hvor alene tiden sætter sig fast i tiden.
Det er i hvert fald, hvad der vil ske, når holdet “får det”:
- Du behøver ikke længere at beregne personer eller dage for at vide, hvornår noget kan gennemføres.
- Holdet lærer kun at skabe historier så komplekse, at de passer ind i en sprint. Hvis en historie er mere kompleks, bliver den automatisk opdelt i flere historier.
- Holdet har gode estimater for hvert stykke arbejde, og når de først planlægger det til en sprint, ved du præcis, hvornår det skal betales.
- Det vil øge holdets pålidelighed og forudsigelighed.
- Alle personer i teamet vil være “på samme frekvens”. De vil se på en historie og vil forstå lignende ting. Måske efter noget tid, gider de ikke engang at vurdere. De ser tallet i deres hoved, og da de alle ser det samme tal, kan de forpligte sig til historier i en spurt selv uden dette eksplicitte skøn.
Og dette er, hvad der normalt sker, hvis teamet stadig ikke er i stand til at forstå processen eller måden at arbejde på:
- På en eller anden måde holder de sig stadig til de gammeldags man-dages skøn. De konverterer alt til dage eller involverede personer. Historiepoint eller Fibonacci-tal betyder antal dage, enten direkte eller indirekte, via forskellige transformationer.
- Lederskab sammenligner holdene baseret på antallet af historiepoint leveret hver sprint. Dette er så meget forkert, som det kan blive. Et væsentligt faktum er så ikke forstået: Hvert hold vurderer historiepointene forskelligt. Der er absolut ingen grund til at gøre en indsats for at synkronisere to hold for at vurdere deres historier på “samme måde”.
- Mens et holds historiepunkt betyder at tegne en cirkel, kan det for et andet hold betyde at tegne et hus med et fladt tag, fire vinduer og to døre. Og det er helt fint.
- Nogle gange har holdene en tendens til at estimere næsten alt mellem to til fire forskellige tal. Måske fordi de frygter, at en historie har tallet 123, vil nogen tro, at det har noget at gøre med antallet af dage. Men faktum er, at Fibonacci-skalaen har en uendelig mængde tal. Vi behøver ikke at begrænse os til kun at vurdere 3, 5 eller 8. Det kan vi helt sikkert (og måske skaber vi historierne allerede med det formål i tankerne, så de er så komplekse, i så fald er det fint), men vi behøver bestemt ikke.
- Estimering er drevet af seniorpersoner, som vil foruddefinere forventningerne til hele gruppen. Vi bør aldrig tillade, at et teammedlem påvirker estimeringen. Alle har lige ret til at udtrykke sin mening og blive lyttet til.
Afsluttende ord
Det er ikke altid let at skifte til agil estimering fra de mere traditionelle tilgange – både for teamene og for ledelsen ovenfor. For at få det til at fungere, skal begge sider forstå processen. Hvis en af dem ikke forstår, er overgangsperioden en vanskelig vej fuld af modstridende forventninger.
Men når det hele forvandler sig, vil nogle magiske ting begynde at ske. Holdene vil bedre kunne estimere og planlægge deres arbejde, og ledelsen vil have mere forudsigelige udgivelser og køreplaner at stole på.
Dernæst skal du tjekke usunde processer, der kan ødelægge din sprint.