I dette indlæg vil jeg gå i dybden med koncepterne estimering og velocity. Jeg starter ud med et overblik over de vigtige roller, som estimering og velocity spiller i agil planlægning.
Derefter diskuterer jeg de forskellige items som vi estimerer og hvornår og hvordan vi estimerer dem.
Størstedelen af indlægget fokuserer på hvordan man kan estimere product backlog items, hvilket inkluderer hvordan man kan vælge en måleenhed og bruge Planning Poker.
Derefter går jeg videre til konceptet velocity og hvordan det at bruge velocity range er essentielt for planlægning. Jeg diskuterer hvordan nye projektgrupper kan estimere velocity, hvis der er mangel på historisk data.
Sidst konkluderer jeg med måder vi kan have indflydelse på velocity og hvordan velocity kan blive misbrugt.
Overblik
Når vi skal planlægge og håndtere udviklingen af et projekt, så skal vi besvare vigtige spørgsmål, som f.eks. “Hvor mange features får vi færdiggjort?” “Hvornår vil vi være færdige?” og “Hvor meget vil dette koste?”.
For at besvare disse spørgsmål med Scrum, så skal vi estimere størrelsen på det vi bygger og måle velocity eller en hastighed som vi kan gøre arbejde færdig på.
Med denne information kan vi finde frem til den sandsynlige product development tidslængde (og hvor meget det koster) ved at dividere den estimeret størrelse af et sæt af features med projektgruppens velocity.
Ud fra projektets product backlog, hvor meget tid skal vi så bruge på at lave alle features i release 1?
For at besvare det spørgsmål, så skal vi først estimere størrelsen på release 1. Vi kan gøre dette ved at samle de individuelle størrelses estimater for hver Product Backlog Item, som vi vil opnå i release 1.
Når vi kender denne størrelse af vores release, så skifter vi vores fokus til projektgruppens velocity, altså hvor meget arbejde projektgruppen typisk bliver færdig med i hver sprint.
Velocity er nemt at måle. I slutningen af hver sprint, så lægger vi alle størrelses estimaterne af hver items, som blev færdiggjort i denne sprint, sammen. Hvis en item ikke er færdig, så tæller den ikke i velocity. Summen af alle de størrelses af alle de færdige product backlog items i en sprint er projektgruppens velocity i den sprint.
Efter vi har estimeret størrelsen og målt velocity, så er vi i en position til at udregne tidslængden. For at gøre dette, så dividere vi blot størrelsen med vores velocity.
Hvis størrelsen på release 1 er 200 points og projektgruppen gennemsnitligt kan færdiggøre 20 points af arbejde pr. sprint, så bør det tage projektgruppen 10 sprints at færdiggøre release 1.
Senere i dette indlæg vil jeg forklare hvorfor det at bruge velocity range til at lave disse beregninger er mere præcist end at bruge gennemsnitlig velocity, men for at forsimple det, vil jeg bruge gennemsnitlig velocity her.
Selvom det basale forhold mellem størrelse, velocity og tidslængde er det samme, så kan nogle detaljer variere baseret på hvor du er i projektet, hvad du forsøger på at måle, og hvordan du har tænkt dig at bruge dataene.
Lad os kigge tættere på estimering og velocity for at se hvordan disse faktorer ændrer sig alt efter hvad du forsøger på at gøre og hvornår.
Hvad og hvornår vi estimerer
Tidligere brugte vi story points til at beskrive Product Backlog Item estimeringer til at beregne en release tidslængde. Gennem udviklingen af et projekt bliver vi dog nødt til at estimere på forskellige niveauer af granularitet og vi vil derfor have behov for at bruge forskellige måleenheder.
De fleste organisationer laver estimater til planlægningsformål på tre forskellige niveauer af detaljer. Disse estimater manifesterer sig selv i ens portfolio backlog, product backlog og sprint backlog. Lad os kort kigge på hver.
Portfolio backlog Item estimeringer
Selvom en portfolio backlog ikke formelt set er en del af Scrum, så vedligeholder mange organisationer en, som indeholder en prioriteret liste af alle produkter (eller projekter) som skal bygges.
For at prioritere en portfolio backlog item skal vi kende til den estimeret cost af hver item. Typisk vil vi ikke have et komplet, detaljeret sæt af krav når dette skal estimeres første, så vi kan ikke bruge de standard teknik med at estimere hver individuelt, detaljeret krav og så finde summen af disse estimater for at få et samlet estimat af den samlede tid det vil kræve at komme i mål med opgaven.
I stedet, for at estimere portfolio backlog items, vælger mange organisationer at bruge relative size estimater, som T-shirt størrelser (XS, S, M, L, XL, osv).
Product backlog estimeringer
Når er et produkt eller projekt er blevet godkendt og vi begynder at tilføje flere detaljer til dets product backlog items, så skal vi estimere på en anden måde. Når Product Backlog Items er steget i prioritet og er blevet groomed til at inkludere flere detaljer, så foretrækker de fleste projektgrupper at tilføje numeriske estimater på dem, enten ved brug af story points eller ideal days. Senere i indlægget vil jeg gå mere i dybden med begge disse tilgange.
Estimering af Product Backlog Items er en del af den overordnet product backlog grooming aktivitet. Typisk, så opstår Product Backlog Item estimering i “estimerings-møder”, hvor det første møde typisk vil finde sted i takt med release planlægning. En product owner vil måske indkalde til yderligere estimerings-møder under en sprint, hvis nye Product Backlog Items skal estimeres.
Ikke alle Scrum projektledere mener, at Product Backlog Item størrelses-estimering er en nødvendig aktivitet. Deres erfaringer har vist, at når Scrum projektgrupper bliver gode nok, så er de i stand til at lave Product Backlog Items som er små og nogenlunde den samme størrelse.
Sådanne projektledere har vurderet, at det er spild af tid at estimere små items, som er i nogenlunde samme størrelse. I stedet, så tæller de blot antallet af Product Backlog Items.
De bruger stadig velocity konceptet, men det er målt som antallet af Product Backlog Items der er færdiggjort i en sprint, i stedet for summen af størrelserne af de Product Backlog Items der er færdiggjorte i en sprint.
Jeg kan godt følge dette argument, men foretrækker stadig at estimere Product Backlog Items af nogle forskellige årsager:
- Ikke alle Product Backlog Items vil være af samme størrelse på samme tid, så der vil være nogle større Product Backlog Items i ens backlog selv hvis vi har en samling af mindre items af nogenlunde samme størrelse i toppen.
- Det kan tage noget tid for projektgrupper af få evnerne til at nedbryde Product Backlog Items til at være i ca. samme størrelse.
- Projektgrupper bliver måske nødt til at splitte stories på unaturlige tidspunkter for at opnå målet om samme størrelser.
- Sidst, og vigtigst af alt, så er en af de primære værdier af estimeringer den læring som finder sted under estimerings-samtalerne. Intet promoverer en sund debat som at spørge folk om at sætte et tal på noget, hvilket automatisk vil få uenigheder til overfladen og tvinge antagelser til at komme frem. Hvis vi ville gøre det hele uden estimeringer, så vil vi blive nødt til at finde en anden lige så effektiv måde at finde frem til disse sunde diskussioner.
Opgave estimeringer
På det mest detaljeret niveau har vi opgaver, som er i ens sprint backlog. De fleste projektgrupper vælger at sætte estimater på deres opgaver under en sprint, så de kan være helt sikre på de forpligtelser de finder fair.
Opgave Størrelser beskrives i ideal hours (også refereret til som effort-hours, man-hours eller person-hours). Hvis f.eks. en projektgruppe estimerer at en opgave vil tage fem effort-hours at gennemføre, så betyder det ikke at den vil være færdig om fem timer.
Det kan være, at det tager en person et par dage at gennemføre opgave eller at det tager en gruppe af personer under en dag.
Estimatet beskriver blot hvor meget af projektgruppens indsats man forventer, at det vil tage at gennemføre denne opgave.
Product Backlog Item estimerings-koncepter
Selvom at alle tre niveauer af detaljer er vigtige, så vil resten af dette indlæg fokusere på product-backlog level estimering.
Der er flere vigtige koncepter som Scrum projektgrupper bruger når de skal estimere Product Backlog Items. Lad os kigge nærmere på hver koncept.
Estimering som en projektgruppe
I mange traditionelle organisationer, der vil projektlederen, product owneren, arkitekten eller lederen af udviklingen muligvis foretage den første størrelses estimering.
Andre medlemmer af projektgruppen får så en chance for at gennemgå og kommentere på disse estimater på et senere tidspunkt. Med Scrum, der følger vi en simpel regel: De personer som skal lave arbejdet, vil sammen finde frem til estimaterne.
For at være tydelig, når jeg siger de personer som skal lave arbejdet, så mener jeg udviklingsholdet som skal lave hands-on arbejdet med design, bygge og testning af Product Backlog Items.
Product owner bør ikke guide eller føre et hold hen i mod et ønsket estimat. ScrumMasterens rolle er at hjælpe med at vejlede og facilitere estimerings-aktiviteten.
Målet er for udviklingsholdet er at vurdere størrelsen af hver Product Backlog Item fra dets kollektive perspektiv. Da alle ser en story fra forskellige perspektiver, alt efter personens område af ekspertise, så er det vigtigt at alle medlemmer af udviklingsholdet deltager under estimeringen.
Estimeringer er ikke forpligtelser
Estimeringer er ikke forpligtelser og det er vigtigt, at vi ikke behandler dem således. Denne statement vedrører typisk ledere. “Hvad mener du med at vi ikke beder projektgruppen om at forpligte sig til sine estimater? Hvordan får vi præcise estimater medmindre de gør?”
Når man får personer til at estimere størrelsen på en story, som får en bonus for at finde frem til den korrekte størrelse, så vil de typisk komme frem til en større størrelse end uden bonussen.
Målet bør være, at finde frem til så realistiske størrelser som muligt uden at de er unødvendigt store, samtidigt med at det også er realistisk at projektgruppen kan nå det.
Når det er sagt, så er sandheden dog, at det er svært at vide hvad den korrekte størrelse er, da mange mennesker er inde over det. Det handler derfor om at stole på, at kollektivet i samarbejde kan finde frem til så god en størrelse som muligt.
Nøjagtighed vs. præcision
Vores estimater bør være nøjagtige uden at være for præcise. Vi har alle været involveret med projekter, hvor estimaterne var på et absurd niveau af præcision. Du har sikkert oplevet det, hvor et af estimaterne var 10,225 man-hours eller det andet, hvor projektet skulle koste $123,765.79.
Det er spild af tid at generere disse forkerte og alt for præcise estimater. Først og fremmest, så er der spildtiden med at komme op med estimatet, som godt kan være meget tid.
Derudover er der det spild der opstår, når vi tvinger os selv til at tro, at vi forstår noget, som vi ikke forstår, og så laver vigtige, forkerte og dyre forretningsbeslutninger baseret på dette.
Vi bør investere nok tid til at vi kan få et “godt-nok” og nogenlunde rigtigt estimat.
Når man laver estimater, så vil der altid være et punkt af faldende afkast, hvor efter hver ekstra enhed af indsats vi investere, der får vi ikke en tilsvarende stigning i nøjagtigheden af vores estimat.
Efter det punkt, der spilder vi bare vores tid og begynder højst sandsynligt at påvirke nøjagtigheden af estimatet negativt, da vi der vil benytte en stigende mængde af data af lav værdi.
Relativ størrelses estimering
Vi bør estimere Product Backlog Items ved brug af relative størrelser, ikke absolutte størrelser. Vi sammenligner items for at vurdere hvor stor en item er relativt til andre.
Mine erfaringer:
Mine personlige observeringer er, at folk er meget bedre til relativ størrelse estimeringer end absolutte størrelse estimeringer. Pointen er, at når vi beder folk om at lave estimater, så bør de gøre det på en måde som de er gode til (relativ størrelses estimater) og ikke det de er dårlige til (absolut størrelses estimater).
Product Backlog Item estimerings-enheder
Selvom der ikke er nogen standard enhed for Product Backlog Item størrelses-estimater, så er de to enheder, som er klart mest brugt story points og ideelle dage.
Der er ikke et rigtigt eller forkert valg, når du skal vælge mellem disse to. Mit bud er at ca. 70% af organisationer arbejder med story points og de andre 30% bruger ideelle dage. Lad os kigge nærmere på hver.
Story Points
Story points måler størrelsen af en Product Backlog Item. Vi forventer, at story points bliver påvirket af mange forskellige faktorer, som f.eks. kompleksitet og størrelse. Opgaven behøver ikke at være “fysisk” stor for at være en stor opgave.
En story kan måske repræsentere udviklingen af en kompleks forretningsalgoritme. Slutresultatet virker måske ikke specielt stort, men derfor kan det godt være, at indsatsen der er krævet har været stor.
På den anden side kan det også være, at en story måske er fysisk meget stor, men ikke specielt kompleks. Lad os sige, at vi skal opdatere hver celle i et 60.000-celle ark. Ingen af de individuelle opdateringer er svære, men det er ikke muligt at automatisere dem. Hvor meget af dette arbejde kan gøres i en sprint? Selvom det ikke er komplekst, så vil det blive en meget stor story.
Story points kombinerer faktorer som kompleksitet og fysisk størrelse om til en relativ størrelses-enhed. Målet er at gøre det muligt at sammenligne stories og sige ting som “Hvis opgaven lav login side er en 2, så er valider brugeren adgangskode og email en 8”, hvilket repræsenterer at søge-storyen er ca. fire gange størrelsen af create storyen.
Til at starte med i indlægget gennemgik jeg tilgangen med at estimere Product Backlog Item størrelser og så finde frem til tidslængden ved at dividere summen af alle størrelser med den gennemsnitlige velocity. Da størrelses-måleenheder som story points ultimativt set er brugt til at beregne tid, så skal story points vise den indsats der er passende til en story fra udvikler holdets perspektiv.
Ideelle Dage
En alternativ tilgang til at estimere Product Backlog Items er at bruge ideelle dage. Ideelle dage er en genkendelig enhed – de repræsentere antallet af indsats-dage eller person-dage som skal bruges for at gennemføre en story.
Ideel tid er ikke det samme som tid gået. Ideelt set har Amerikansk fodbold fire quarters, som hver er 15 minutter lange (så spillet ideelt set er spillet på en time). Men, det tager rent faktisk nærmere tre timer at spille kampen færdig.
Jeg beskrev tidligere, at der ikke er noget rigtigt eller forkert svar, når man skal vælge mellem story points eller ideelle dage. Men, en vigtig faktor i mod ideel tid er risikoen for misforståelser.
Eksempel:
Det er tirsdag eftermiddag og jeg viser dig en Product Backlog Item og spørger “Hvor stor er denne Product Backlog Item?” Du siger “To dage”. Dertil svarer jeg “Okay, så du er færdig torsdag eftermiddag”, hvortil du svarer “Nej jeg er ved at færdiggøre en to-dags aktivitet denne eftermiddag og imorgen. Jeg har brug for hele dagen bare for at blive oplyst, så jeg kan sikkert stadig på denne Product Backlog Item på torsdag. Men siden jeg ikke har nogle fulde dage til at dedikere til denne Product Backlog Item, så tænker jeg at den er færdig næste mandag.” Hertil kan jeg svare “Det forstår jeg ikke, du sagde at det var en to-dags Product Backlog Item, så du bør være færdig på torsdag.” Du siger “Jeg sagde to ideelle dage, ikke to kalenderdage. Du kan ikke sætte ideelle dage ind i min kalender, det virker ikke sådan.”
For omkring 30% af organisationer som bruger ideel tid, så er deres kommentar typisk, at de ikke har dette problem, da de godt kender forskellen.
Hvis der er en lav risiko for misforståelser i din organisation, så vil ideel tid højst sandsynligt virke helt fint. Hvis du dog frygter, at folk vil misforstå ideel tid, så er det nemmere at bruge story points.
Der er andre forskelle mellem story points og ideel tid, men misforståelser er en af de store problemer.
Planning Poker
Planning Poker er en teknik til at komme med størrelser på Product Backlog Items, som først blev beskrevet af James Grenning og senere hen gjort meget populær af Mike Cohn. Planning Poker er baseret på nogle få vigtige koncepter:
- Planning Poker er en konsensus-baseret teknik til at estimere indsats.
- Eksperter der er sat til at arbejde på en Product Backlog Item deltager i en intens diskussion for at fremhæve antagelser, for at opnå en delt forståelse og for at finde frem til størrelsen på den gældende Product Backlog Item.
- Planning Poker giver relative størrelse estimater ved at præcist gruppere eller samle ting sammen af samme størrelse.
- Projektgruppen udnytter dens etablerede estimerings-historie til at have lettere ved at estimere næste sæt af Product Backlog Items.
Estimerings-skala
For at udføre Planning Poker, så skal projektgruppen vælge hvilken skala eller sekvens af numre den vil bruge til at uddele estimater. Fordi vores mål er at være nøjagtige og ikke for præcise, så foretrækker vi ikke at bruge alle numrene. I stedet, så foretrækker vi en skala af størrelser med flere tal i den lille ende og færre, mere spredte tal i den store ende.
Den mest brugte skala er en, som er foreslået af Mike Cohn, som er baseret på en modificeret Fibonacci sekvens: 1, 2, 3, 5, 8, 13, 20, 40 og 100. En alternativ skala som nogle projektgrupper bruger er baseret på tallet gange 2: 1, 2, 4, 8, 16, 31,..
Når man bruger denne type skala, så gruppere vi Product Backlog Itemer af samme størrelser og giver dem samme tal på denne skala. Et godt eksempel er hvis man arbejder ved et postkontor. Når man modtager en pakke, så skal den placeres i den rigtige beholder. Naturligvis, så er alle pakker i den samme beholder ikke af samme fysiske form, størrelse eller vægt, så vi skal eksaminere pakkerne der på nuværende tidspunkt er i de forskellige beholdere, så vi kan finde den beholder, som pakken passer bedst til. Jo flere pakker der er i hver beholder, jo nemmere bliver det at finde frem til hvilke pakker der skal i hver beholder.
Hvordan du kan bruge Planning Poker
Hele Scrum projektgruppen deltager når man udfører Planning Poker. Under disse sessioner fremhæver, beskriver og forklarer produktets product owner Product Backlog Items.
Projektets ScrumMaster vejleder projektgruppen med at blive bedre til at bruge Planning Poker. En ScrumMaster er også konstant på udkig efter at holde øje med personer, som gennem deres kropssprog eller stilhed, virker til at være uenige og hjælper dem med at deltage. Og udviklingsholdet generer kollektivt estimaterne.
Reglerne af Planning Poker er som følgende:
- Hver projektgruppe medlem er givet et sæt af Planning Poker cards.
- En product owner vælger en Product Backlog Item som skal estimeres og læser en item fra denne Product Backlog Item højt for projektgruppen.
- Udviklings-medlemmer diskuterer denne item og spørge fordybende spørgsmål til deres product owner, som besvarer spørgsmålene.
- Hver estimator vælger omhyggeligt et kort, som repræsentere hans/hendes estimat.
- Når hver estimator har lavet et privat valg, så vises alle de private estimater samtidigt til alle andre.
- Hvis alle har valgt det samme kort, så har vi konsensus og denne konsensus bliver Product Backlog Items estimat.
- Hvis estimaterne ikke er de samme, så deltager medlemmerne i en fokuseret diskussion til at fremhæve antagelser og misforståelser. Typisk starter man ved at spørge dem der har valgt høje og lave estimater, så de kan forklare eller retfærdiggøre deres estimater.
- Efter diskussionen går man tilbage til step 3 og gentager indtil der er konsensus.
Med Planning Poker tager vi ikke gennemsnittet eller bruger noget tal på skalaen/kortene. Målet er ikke at gå på kompromis, men i stedet for udviklingsholdet at nå en konsensus om estimatet af en story’s overordnede størrelse (indsats) fra projektgruppens perspektiv.
Typisk så kan denne konsensus opnås inden for to eller tre runder af stemmer, hvor projektgruppens fokuseret diskussion hjælper med at opnå en delt forståelse af en story.
Fordele ved Planning Poker
Planning Poker bringer forskellige projektgrupper af folk sammen, som skal gøre arbejdet og tillader dem at nå en konsensus på et nøjagtigt estimat som typisk er meget bedre end et enkelt individ kunne producere.
Som jeg nævnte tidligere, så er der nogle i det agile samfund, som mener, at det ikke er det værd at estimere Product Backlog Items. Den intense diskussion af Product Backlog Items, som Planning Poker fremtvinger er dog ekstremt værdifuld. Efter min erfaring, så kan du virkelig motivere folk til at tænke på detaljerne af Product Backlog Items og belyse alle antagelser, når du beder dem om at sætte et tal på dem.
Størstedelen af værdien der er tilknyttet til Planning Poker er diskussionen og bedre forståelse, som medlemmerne vil dele omkring den gældende Product Backlog Item. Jeg håber de også får estimater på størrelsen på en Product Backlog Item, men det er vigtigere, at de lærer en masse om den gældende Product Backlog Item.
Hvis de gør, så har de fået et godt return på projektgruppens investering.
Hvad er Velocity?
Velocity er mængden af færdiggjort arbejde pr. sprint. Det er målt ved at tage summen af alle estimaterne på alle de forskellige Product Backlog Items der er færdiggjorte i slutningen af en sprint.
En Product Backlog Item er enten færdig eller ikke færdig. En product owner får ikke nogen værdi fra items, som ikke er færdige, så velocity inkluderer ikke størrelserne på Product Backlog Items, som ikke er helt færdige endnu.
Velocity måler output (størrelsen på det der blev leveret), ikke outcome (værdien på det der blev leveret). Vi antager, at hvis en product owner har aftalt at projektgruppen skal arbejde på en Product Backlog Item, så skal det have værdi for ham. Men, færdiggørelse af en Product Backlog Item med størrelsen 8 behøver ikke nødvendigvis at levere mere forretningsværdi end færdiggørelsen med en Product Backlog Item med størrelsen 3.
Måske så er Product Backlog Item’en af størrelsen 3 af høj værdi og derfor vil vi arbejde på den tidligt (høj værdi, og lille størrelse) og vi arbejder på en Product Backlog Item af størrelsen 8 senere (lav værdi, men større størrelse).
Velocity bruges til to vigtige formål. For det første, så er det et essentielt koncept til Scrum planlægning.
Til release-level planlægning, der dividerer vi størrelsen af selve releasen med projektgruppens gennemsnitlige velocity for at beregne antallet af sprints der er nødvendige for at gennemføre en release.
Derudover, med sprint planlægning, bruges en projektgruppes velocity som et input til at hjælpe med at vurdere dets kapacitet til at forpligte sig til arbejde under den kommende sprint.
Velocity er også en diagnostisk måleenhed, som projektgruppen kan bruge til at evaluere og forbedre dens brug af Scrum for at levere kundeværdi.
Ved at observere gruppens egen velocity over tid kan projektgruppen få indsigt i hvordan bestemte processer ændrer leveringen af målbar kundeværdi.
Beregning af en Velocity skala
For planlægnings-formål er velocity mest brugbart, når det udtrykkes som en skala, som f.eks. “Projektgruppen er typisk i stand til at gennemføre mellem 25 og 30 points hver sprint.”.
Det at bruge en skala tillader os at være nøjagtige uden at være for præcise.
Med en velocity skala kan vi mere præcist give svar til spørgsmål som “Hvornår vil vi være færdige?” “Hvor mange items kan vi færdiggøre?” eller “Hvor meget vil alt dette koste?”
Fordi de fleste af disse spørgsmål bliver spurgt om tidligt i produkt-udviklings-indsatsen, når vi har den mindst mulige information omkring produktet, så er det umuligt at give et meget præcist svar. Ved at bruge en skala, så kan vi kommunikere hvor usikre vi er.
I stedet for at erklære den præcise sprint hvor alle items i en release vil blive færdiggjort (hvilket sikkert vil være gæt fra leverandørens side), så leverer vi i stedet en skala som svar til dette spørgsmål. For at beregne denne skala skal vi bruge to velocities til vores projektgruppe.
Hvis vi dividerer en release størrelse med projektgruppens højeste velocity, så får vi det færrest antal af sprints kræves. Og hvis vi dividerer en release størrelse med projektgruppens laveste velocity, så får vi et større antal af sprints.
Ved brug af simpel matematik (som høj-lav gennemsnit, 90%-confidence interval, osv.), så kan vi nemt finde to velocity tal fra vores projektgruppes historiske velocity data.
Prognose af velocity
I de tidligere eksempler antog jeg af projektgruppen havde historisk velocity-data, som de kunne bruge til at forudsige fremtidig velocity.
En af fordelene ved at have langlivet projektgrupper er at de vil danne brugbar historisk data. Men hvordan håndterer vi situationen, hvor vi har en ny projektgruppe, hvis medlemmer ikke har arbejdet sammen og derfor ikke har nogen form for historisk data. Her bliver vi nødt til at lave en prognose.
En typisk måde at lave en prognose på projektgruppens velocity er ved at få holdet til at udføre sprint planlægning for at vurdere hvilke Product Backlog Items det kan forpligte sig til at levere under en enkelt sprint.
Hvis disse forpligtelser virker fornuftige, så vil vi simpelthen bare samle summen af alle disse størrelser af de forpligtede Product Backlog Items og bruge det som projektgruppens forudsagte velocity.
Fordi det vi gerne vil have er en velocity skala, så kan vi få projektgruppen til at planlægge to sprints og bruge et estimeret velocity tal som det høje og det andet som det lave (de to estimater vil jo sandsynligvis være forskellige). Alternativt kan vi lave nogle fornuftige ændringer til en estimeret velocity baseret på historisk data for andre projektgrupper, og derigennem konvertere det ene estimat om til en to-estimat skala.
Så snart projektgruppen har udført en sprint og vi har en faktisk velocity størrelse, så bør vi kassere prognosen og bruge det faktiske tal. Og som projektgruppen opbygger en historie af faktiske velocities, så kan vi beregne gennemsnittet eller bruge andre statistikker på dataen for at danne en velocity skala.
Påvirkning af velocity
Mener du at en projektgruppes velocity konstant bør stige over tid? En jeg kender har engang sagt: “Sidste år nåede min projektgruppe en velocity på gennemsnitligt 30 points pr. sprint. Dette år forventer jeg, at projektgruppen når 35 points pr. sprint.” Denne person mener, at projektgruppens velocity bør følgende gruppens nuværende trend.
Hans ræsonnement var at hvis projektgruppen hele tiden holder øje og tilpasser sig, så bør gruppens velocity også hele tiden blive bedre og bedre.
Jeg vil også forvente, at en projektgruppe som hele tiden forsøger på at forbedre sig selv og er fokuseret på at levere features ifølge en robust definition of done og lav teknisk gæld, at det vil medføre en stigning i velocity. I det mindste op til et punkt, hvor projektgruppens velocity derefter vil nå et plateau.
Bare fordi en projektgruppens velocity ikke længere stiger betyder det ikke, at der ikke længere er upward potentiale. Der er flere forskellige måder, som Scrum projektgrupper og ledere kan hjælpe med at tage velocity til næste niveau.
For eksempel, så vil introduktionen af nye redskaber eller øget træning have en positiv effekt på velocity. Eller ledere kan strategisk ændre kompositionen af projektgruppen med et håb om at ændringen vil føre til en større overordnet velocity. Selvfølgelig, så bør ledere være forsigtig fordi det at flytte rundt på folk kan få velocity til at falde.
Selvom introduktionen af nye redskaber, træning eller ændringer af projektgruppernes komposition kan have en positiv effekt på velocity, så vil disse handlinger typisk medføre tilbagegang i velocity imens gruppen tager disse ændringer og processer til sig.
Efter faldet, så vil der garanteret være en stigning indtil det punkt, hvor gruppen når et nyt plateau indtil nogle nye ændringer finder sted for igen at opnå et endnu højere plateau.
Naturligvis, så er der en åbenlys ting vi kan gøre for at forbedre velocity; og det er at arbejde flere timer. Det at arbejde meget på kontinuerlig basis på overtid kan dog også medføre et tab i velocity.
Denne stigning vil derfor næsten helt sikker blive efterfulgt af et aggressivt fald i velocity samtidigt med at der vil være et fald i kvalitet.
Selv efter perioden med overarbejde slutter, så vil projektgruppen have brug for tid til at komme sig over overarbejdet før man kan gå tilbage til en fornuftig mængde af velocity igen.
Jeg har også set en del eksempler hvor folk har brug for en ferie efter sådan en over arbejdsperiode, før at de kommer op på samme velocity som før over arbejdsperioden igen.
Så slutresultatet er tit, at hvor en masse overarbejde kan give nogle gode kortsigtede fordele, men disse fordele som regel opvejet af de langtidssigtede konsekvenser, så det kan tit have en negativ effekt på projektets overordnet velocity.
Misbrug af velocity
Velocity bruges som et planlægningsværktøj og som en diagnostisk enhed. Det bør ikke bruges som en performance-enhed i et forsøg på at måle projektgruppens produktivitet. Når man misbruger det på denne måde, så kan velocity motivere spildfuldt og farligt adfærd.
Hvis for eksempel jeg har valgt at give den største bonus til den projektgruppe, som har den højeste velocity. Overordnet set kan det måske godt være, at denne ide lyder fornuftig; den projektgruppe som har den højeste velocity må også være den projektgruppe, som får mest arbejde gjort færdigt i hver sprint, ikke? Så hvorfor ikke belønne det adfærd?
Men.. hvis man sammenligner projektgrupper, som ikke finder størrelser på deres Product Backlog Items ved brug af den samme baseline (hvilket højst sandsynligt er tilfældet), så vil det ikke give mening at sammenligne disse tal.
Forestil dig, at projektgruppe A har en værdi på 5 på en Product Backlog Item, hvor projektgruppen B tildeler en værdi af 50 til samme Product Backlog Item.
Projektgruppe A vil ikke have mig til at sammenligne deres velocity mod B-gruppens. Projektgruppe B’s velocity vil være ti gange så stor som projektgruppe A’s, selv på trods af at begge grupper rent faktisk for den samme mængde arbejde gjort færdig i hver sprint.
Når projektgruppe A ser problemet, så vil medlemmerne begynder på at “game” systemet for at sikre, at deres velocity tal er højere. Den nemme måde at gøre dette på er blot ved at ændre skalaen, som grupperne bruger til at estimere Product Backlog Items.
Eksempel kan være, når projektgruppe A nu giver en størrelse på den samme item. Dette punkt kan man kalde for point-inflation og bidrager ikke med andet end at få lederne til at arbejde ud fra forkerte informationer og systemer.
- Selv hvis projektgrupper bruger de samme enheder til at finde størrelsen på deres Product Backlog Items, hvis du sætter et reward system, så vil det også resultere i større tal.
- Hvad der er endnu værre end et punkt af inflation, er når projektgruppen springer over hjørnerne for at nå højere og bedre velocities. At gøre dette fører til øget niveauer af teknisk gæld.
- Vi bør vurdere velocity på hvor godt det hjælper os med at udføre nøjagtig planlægning og hvor godt det hjælper vores projektgruppe til at internt forbedre sig selv. Brugen af velocity på nogen anden måde vil sandsynligvis føre til det forkerte adfærd.
Konklusion
I dette indlæg diskuterede jeg hvordan størrelser er estimeret, velocity er mål og tidslængden er beregnet. Jeg illustrerede hvordan estimater kan bruges til forskellige portfolio-items, product backlog items og opgaver.
Jeg fokuserede derfor specifikt på Product Backlog Items ved at diskutere vigtige koncepter relaterede til Product Backlog Item estimeringen, inklusiv story points og ideelle dage. Derefter beskrev jeg en teknik, som er kendt som Planning Poker, som ofte bruges til at estimere Product Backlog Items med.
Jeg gik videre fra estimering til en diskussion af velocity og hvordan man bør bruge det. Jeg forklarede derfor hvorfor velocity er meget hjælpsomt, når det forkortes som en skala i stedet for at bruge enkelte tal. Jeg nævner kort måder, som vi kan bruge til at forudsige en velocity for et nyt hold. Jeg konkluderede ved at diskutere hvordan velocity kan bruges og misbruges.
