10.15 Estimering og prognoser

Overblik og motivation

Hvert softwareteam bliver stillet det samme spørgsmål: hvornår er det færdigt? Bag det spørgsmål sidder estimering af softwareudviklingsindsats, praksissen at forudsige, hvor meget arbejde noget vil tage, før I har gjort det. Det er en af de sværeste ting, vi gør, og en af de letteste at gøre dårligt. Problemet er, at software er opdagelsesarbejde. I bygger noget, der aldrig har eksisteret, og meget af det, I vil lære om problemet, bliver kun synligt, mens I bygger. At forudsige indsatsen ved at lære er reelt anderledes end at forudsige indsatsen ved at gentage en kendt opgave.

Hvorfor behandle dette som sin egen disciplin frem for et hjørne af projektstyring (kapitel 10.6)? Fordi fejlene er så konsekvente og så dyre. Teams forpligter sig rutinemæssigt på enkelte datoer, de ikke har dokumentation for, og forsvarer så de datoer langt forbi det punkt, hvor virkeligheden har modsagt dem. Ledere forveksler et estimat med et løfte. Kontrakter fryser et tal produceret på en eftermiddag og holder folk til det i et år. Resultatet er sen levering, eroderet tillid og en kultur, hvor ingen siger, hvad de faktisk tror. At få dette rigtigt handler mindre om bedre matematik og mere om ærlighed: at adskille det, I ved, fra det, I håber, og at kommunikere usikkerhed som usikkerhed.

Indsatsen stiger kraftigt i virksomheds- og offentlige sammenhænge. Virksomheder finansierer porteføljer af sammenflettede initiativer mod årlige budgetter og forventer faste tal til at allokere kapital (kapitel 10.1). Regeringer giver offentlige forpligtelser under bevillingsregler, underskriver fastprisaftaler og svarer til lovgivere, når en dato glider. I begge verdener er presset for at producere et selvsikkert enkelt tal enormt, og den dybe usikkerhed, der gør det tal upålideligt, forsvinder ikke, fordi nogen vigtig vil have sikkerhed. Dette kapitel argumenterer for en anden holdning: estimér, når det hjælper jer med at beslutte, prognosticér med dokumentation frem for optimisme, og sig sandheden om intervallet.

Grundprincipper

Et estimat er en forudsigelse, ikke et løfte. Hold det adskilt fra mål og forpligtelser.
Usikkerhed er reel, så udtryk den. Et interval med en sandsynlighed slår en falsk enkeltdato.
Fortiden forudsiger fremtiden bedre end optimisme gør. Foretræk målt historik frem for friske gæt.
Nedbryd for at forstå, prognosticér for at forpligte. Små skiver reducerer både risiko og behovet for at estimere.
Tag udefrakommende perspektiv. Sammenlign med lignende tidligere indsatser, før I stoler på jeres indre historie.
Genprognosticér kontinuerligt. En forudsigelse lavet én gang og aldrig opdateret er pynt.
Estimér kun, når svaret vil ændre en beslutning. Ellers er det spild.

Anbefalinger

Adskil estimatet, målet og forpligtelsen

Det mest nyttige enkelttræk i hele dette kapitel koster intet: hold tre idéer adskilt. Et estimat er jeres ærlige forudsigelse af, hvor lang tid noget vil tage, med dets usikkerhed knyttet til. Et mål er et forretningsmål, I gerne vil ramme, såsom en messelancering eller en regulatorisk deadline. En forpligtelse er et løfte, I giver nogen andre, og som I agter at holde. Det er tre forskellige ting, og at lade dem falde sammen er, hvordan projekter begynder at lyve for sig selv. Når en leder hører “omkring tre til fem måneder” og skriver “tre måneder” ned, og salgsteamet lover en kunde “tolv uger,” er et estimat stille blevet en forpligtelse, uden at nogen besluttede at acceptere risikoen.

Sig hvilket af dem, I giver, hver gang. Hvis I bliver bedt om en dato, så svar med et estimat udtrykt som et interval, og lad så forretningen sætte et mål mod det og afgøre, bevidst, hvad der skal forpligtes på. En forpligtelse bør være et valg truffet med åbne øjne, der vejer estimatets usikkerhed mod omkostningen ved at misse. Den disciplin hænger direkte sammen med, hvordan jeres organisation træffer og registrerer beslutninger (kapitel 1.5): en forpligtelse er en beslutning, og den fortjener en beslutnings stringens frem for et nik i gangen.

Forstå hvorfor estimater er forkerte, og i hvilken retning

Softwareestimater er ikke tilfældigt forkerte. De er forkerte på forudsigelige, systematiske måder, og at kende mønstret lader jer korrigere for det. Tidligt i enhver indsats sidder I inde i usikkerhedskeglen: ved begyndelsen kan jeres estimat let være forkert med en faktor fire i begge retninger, og intervallet snævrer kun ind, efterhånden som I bygger og lærer. At forpligte sig på et præcist tal ved keglens brede munding er at forpligte sig på et tal, I endnu ikke kan understøtte.

Oven på den strukturelle usikkerhed sidder en menneskelig bias. Planlægningsfejlslutningen er vores pålidelige tilbøjelighed til at undervurdere tid, omkostning og risiko ved vores egne planer, mens vi forestiller os bedste tilfælde. Vi ser den lykkelige sti for os, glemmer afbrydelserne og integrationsoverraskelserne og sygedagene og producerer et tal, der antager, at intet går galt. Polstring er det sædvanlige defensive svar, men polstring tilføjet på fornemmelse er blot et andet gæt stablet oven på det første, og det bliver forhandlet væk i det øjeblik, tidsplaner strammes. Kuren er ikke mere viljestyrke; det er metode. Baser forudsigelser på, hvad lignende arbejde faktisk tog, ikke på, hvordan dette arbejde føles indefra.

Brug dekomposition og ekspertvurdering, og kend deres grænser

Arbejdshestteknikkerne er værd at kende og værd at afgrænse. Dekomposition nedbryder en stor leverance i mindre stykker, I kan ræsonnere om, og ruller så stykkerne op. Den hjælper, fordi folk estimerer små, velkendte ting langt bedre end store, vage, og fordi summering af mange uafhængige poster lader nogle overestimater ophæve nogle underestimater. Dens grænse er, at dekomposition misser arbejdet mellem boksene: integration, koordinering og de opgaver, I ikke tænkte på at liste. Ekspertvurdering og estimering ved analogi (“det her er ligesom rapporteringsmodulet, vi byggede sidste år, som tog to måneder”) er hurtige og ofte overraskende gode, men de arver estimatorens optimisme og blinde vinkler.

For alt, I skal sætte et tal på, så foretræk trepunktsestimering, som beder om et optimistisk, et mest sandsynligt og et pessimistisk tal og kombinerer dem, ofte som PERT-vægtet gennemsnit (optimistisk plus fire gange mest sandsynligt plus pessimistisk, divideret med seks). Værdien er ikke den præcise formel. Den er, at trepunktsestimering tvinger jer til at sige jeres usikkerhed højt og producerer et interval i stedet for et falsk punkt. Relative størrelsesmetoder som story points og t-shirt-størrelser (small, medium, large, extra-large) omgår fælden at forudsige præcise timer ved at sammenligne poster med hinanden. De virker godt til rækkefølge og grov kapacitet, men behandl dem som input til en prognose, ikke som valuta. Points er ikke timer, og at gange velocity med points for at producere en dato genindfører alle de problemer, relativ størrelsesbedømmelse skulle undgå.

Prognosticér probabilistisk ud fra jeres egne flowdata

Her er skiftet, der ændrer alt: hold op med at bede folk gætte, hvor lang tid arbejde vil tage, og begynd at måle, hvor hurtigt jeres team faktisk færdiggør arbejde. Jeres leveringspipeline (kapitel 11.2) producerer allerede de data, I har brug for. Hvis I følger gennemløb, antallet af poster jeres team gennemfører pr. uge, kan I prognosticere fremtiden ud fra fortiden i stedet for ud fra håb. Et team, der har lukket seks til elleve poster om ugen de seneste tre måneder, vil med høj sandsynlighed tage omkring fire til syv uger på at gøre fyrre resterende poster færdige. Den prognose hviler på dokumentation, og den opdaterer sig selv hver uge, efterhånden som nye data ankommer.

Den stringente version kører en Monte Carlo-metode-simulering: træk stikprøver fra jeres historiske ugentlige gennemløb tusindvis af gange for at bygge en fordeling af mulige afslutningsdatoer, og aflæs så svaret som en sandsynlighed. “Vi er 85 % sandsynlige til at blive færdige den 14. marts og 50 % sandsynlige til den 28. februar” er en langt mere nyttig og mere ærlig udtalelse end “det er færdigt den 1. marts.” Denne tilgang hænger direkte sammen med køteori (kapitel 11.3): ledetid er lig igangværende arbejde divideret med gennemløb, så de samme flowmålinger, der styrer, hvordan arbejde bevæger sig, styrer også, hvornår det vil ankomme. Probabilistisk prognose kræver historik og en rimeligt stabil proces, hvilket netop er grunden til, at den belønner teams, der holder arbejde småt og flow jævnt. Den fjerner også stille det meste af estimeringsceremonien, fordi I ikke længere behøver at størrelsesbedømme hver post for at vide, hvornår batchen lander.

Tag udefrakommende perspektiv for store programmer

For store, lange, dyre programmer kan individuelle estimater og selv flowprognoser vildlede, fordi et nyt program endnu ikke har nogen gennemløbshistorik, og dets indre historie er netop, hvor planlægningsfejlslutningen bider hårdest. Modgiften er referenceklasseprognose: find en referenceklasse af lignende afsluttede indsatser, se hvor lang tid og hvor meget de faktisk tog, og placér jeres program i den fordeling, før I stoler på jeres egen bottom-up-plan. Hvis sammenlignelige platformserstatninger i jeres virksomhed i gennemsnit har overskredet deres oprindelige estimater med 60 %, er det tal bedre dokumentation om jeres end den pæne plan, jeres team lige har samlet. Det udefrakommende perspektiv føles nedslående, og det er netop dets værdi: det modvirker den optimisme, hver ny plan bærer. Brug det til porteføljefinansiering og megaprogrambudgettering (kapitel 10.1), hvor omkostningen ved en systematisk overskridelse måles i millioner og i troværdighed.

Estimér mindre ved at skære mindre, og sekvensér efter forsinkelsesomkostning

Nogle gange er den rette mængde estimering næsten ingen. #NoEstimates-argumentet observerer, i sin rimelige kerne, at hvis I skærer arbejde i stykker små nok til, at hvert tager en dag eller to, holder estimatet af et enkelt stykke op med at have betydning. I tæller blot gennemløb og prognosticerer ud fra optællingen. Når skiver er ensartede og små, er omstændelig størrelsesbedømmelse spild: den forbruger indsats på at producere præcision, prognosen ikke behøver. Det er ikke et argument imod at tænke fremad. Det er et argument for at gøre individuelle forudsigelser billige ved at gøre individuelle stykker små.

Hvad der stadig kræver en beslutning, er rækkefølge. Når I ikke kan gøre alt på én gang, så sekvensér efter forsinkelsesomkostning: den værdi, I mister for hver tidsenhed, et givet stykke arbejde er forsinket. En funktion, der låser en stor kontrakt op næste kvartal, har høj forsinkelsesomkostning og bør springe foran et rart-at-have uden nogen, selv hvis det rare-at-have er lettere. At veje forsinkelsesomkostning mod indsats (“weighted shortest job first”-tommelfingerreglen fra lean-tænkning) fortæller jer, hvad I skal gøre næste gang, langt mere pålideligt end et efterslæb sorteret efter mavefornemmelse. Bemærk, at det omformer hele samtalen: i stedet for “hvornår er alt færdigt,” som inviterer til falsk præcision, spørger I “hvad er det mest værdifulde at færdiggøre næste gang,” hvilket I faktisk kan svare på.

Afvejninger: fordele og ulemper

Tilgang	Fordele	Ulemper
Enkeltdatoestimat	Enkelt; det interessenter beder om	Præcist forkert; skjuler risiko; bliver en utilsigtet forpligtelse
Trepunkts-/PERT-estimat	Tvinger usikkerhed frem i åbent lys; billig	Stadig et gæt; formlen antyder falsk stringens
Story points / t-shirt-størrelser	Hurtige; gode til rækkefølge og grov kapacitet	Ikke timer; velocity-matematik smugler enkeltdatoer tilbage
Probabilistisk flowprognose	Dokumentationsbaseret; selvopdaterende; ærlige intervaller	Kræver historik og stabilt flow; ser mindre “sikker” ud
Referenceklasseprognose	Korrigerer optimisme på store programmer	Kræver sammenlignelige tidligere indsatser; nedslående at høre
#NoEstimates (små skiver)	Fjerner spild; prognose ved optælling	Kræver disciplineret skæring; foruroligende for finansiører, der vil have et tal

Den centrale spænding er den sikkerhed, folk vil have, versus den ærlighed, arbejdet kræver. Finansiører, ledere, kontrakter og lovgivere beder om en fast enkeltdato, fordi en enkeltdato er let at budgettere, love og forsvare. Software understøtter sjældent en. Løs spændingen ikke ved at fabrikere sikkerhed og ikke ved at nægte at svare, men ved at svare i sandsynlighedens valuta: et interval med konfidensniveauer, genprognosticeret, efterhånden som dokumentation ankommer. Par det med små skiver, så tidlige, reelle leverancer erstatter fjerne, imaginære som det, folk stoler på. Et demonstreret increment er mere værd end ethvert estimat.

Spørgsmål til drøftelse med dit team

Når nogen beder jer om en dato, giver I så et estimat, et mål eller en forpligtelse, og ved alle i rummet hvilket? Det er det spørgsmål, der forebygger mest skade for mindst indsats. I de fleste organisationer falder disse tre sammen til ét tal i det øjeblik, det forlader teamets mund, og ingen besluttede at acceptere risikoen for, at en forudsigelse blev et løfte. Tag et reelt eksempel med: tag jeres sidste forpligtede deadline, og spor den baglæns til den samtale, hvor den først blev udtalt, og spørg, om den nogensinde var andet end et håbefuldt gæt i jakkesæt. Svaret bør ændre jeres sprog permanent, så estimater går ud som intervaller, mål navngives som forretningsønsker, og forpligtelser gives bevidst med usikkerheden vejet og registreret som en beslutning (kapitel 1.5). Hvis jeres team ikke kan pege på, hvor en forpligtelse bevidst blev accepteret, giver I løfter ved et uheld.
Kunne I prognosticere jeres næste release ud fra målt gennemløb i stedet for friske estimater, og hvad forhindrer jer? De fleste teams har allerede data til at besvare “hvornår er det færdigt” empirisk, liggende ubrugt i det værktøj, der følger deres arbejde. Hvis I ved, hvor mange poster jeres team har gennemført pr. uge det seneste kvartal, kan I simulere en afslutningsdatofordeling og angive en sandsynlighed frem for et ønske. Tag jeres faktiske gennemløbshistorik og jeres resterende postantal med, og sammenlign flowbaseret prognose med den dato, teamet estimerede på fornemmelse; hullet er som regel lærerigt. Hvis blokeringen er, at jeres poster er vildt forskellige i størrelse, eller jeres flow er uregelmæssigt, er det i sig selv fundet, fordi ustabilt flow er et leveringsproblem værd at rette uanset (kapitel 11.2, 11.3). At bevæge sig fra estimering til måling er ofte mindre en værktøjsændring end en beslutning om at stole på jeres egen historik frem for jeres optimisme.
For jeres største nuværende program, har I taget udefrakommende perspektiv, eller kun bygget en indre plan? Store programmer er, hvor optimisme akkumulerer til dyre overskridelser, og hvor en selvsikker bottom-up-plan er mest forførende og mindst pålidelig. Disciplinen er at navngive en referenceklasse af lignende afsluttede indsatser inden for eller uden for jeres organisation, finde hvad de faktisk kostede og hvor lang tid de faktisk tog, og placere jeres program ærligt i den fordeling, før I forsvarer jeres egne tal. Tag dataene med: hvordan har sammenlignelige initiativer her overskredet deres første estimater, og antager jeres nuværende plan stille, at I vil slå hver eneste af dem? Hvis det gør, satser I på at være exceptionelle, hvilket er et væddemål, baserater pålideligt taber. Det udefrakommende perspektiv vil gøre jeres prognose mindre smigrende og langt mere forsvarlig over for de finansiører og revisorer, der vil huske det tal, I gav (kapitel 10.1).
Når en finansiør, en kontrakt eller en lovgiver kræver én fast dato, hvordan svarer I så uden enten at lyve eller nægte? Her er presset hårdest, og her giver ærlige teams oftest efter, fordi “70 % sandsynligt til september” lyder undvigende ved siden af en konkurrents selvsikre “september.” For en stor organisation multipliceres indsatsen: én fast dato breder sig ind i budgetter, afhængige programmer og offentlige løfter, så et tal valgt for komforts skyld bliver et systemisk ansvar i det øjeblik, det glider. Tag det sprog, I faktisk planlægger at bruge, et gennemarbejdet eksempel på et interval med konfidensniveauer og et lille tidligt increment, I kan forpligte jer fast på, mens I efterlader senere omfang som et finansieret interval, med. Det modstridende hensyn er reelt, da nogle deadlines (en regulatorisk omstilling, en messelancering) er reelt faste, og det rette træk der er at fastlåse datoen og lade omfanget bøje sig frem for at foregive, at indsatsen er sikker. I virksomheds- og offentlige sammenhænge så bind dette til, hvordan kontrakten er formet: en modulær, increment-finansieret aftale lader jer forpligte jer ærligt på en værdifuld kerne, mens en enkelt fastpris-, fastomfangskontrakt forankret til en fjern milepæl tvinger netop den falske sikkerhed, der producerer overskridelsen og overskriften.
Hvordan afgør jeres team, hvad der skal bygges næste gang, og ville eksplicit sekvensering efter forsinkelsesomkostning ændre rækkefølgen? De fleste efterslæb er ordnet efter en blanding af mavefornemmelse, hvem der råbte højest og grov indsats, hvilket stille optimerer for lette gevinster frem for værdifulde. Forsinkelsesomkostning, den værdi I mister for hver tidsenhed, et stykke arbejde er forsinket, omformer spørgsmålet fra “hvornår er alt færdigt” til “hvad er det mest værdifulde at færdiggøre næste gang,” som I faktisk kan besvare med dokumentation. Tag tre eller fire reelle efterslæbspunkter med et ærligt estimat af den værdi, hvert låser op, og hvornår den værdi udløber, med, og rangér dem så efter tabt-værdi-pr.-uge mod indsats, og sammenlign den rækkefølge med jeres nuværende plan; omordningen er som regel overraskende og svær at argumentere imod. Det modstridende hensyn er, at forsinkelsesomkostning selv er et estimat og kan manipuleres af den, der vil have sit punkt først, så navngiv, hvem der ejer tallene, og hvordan de udfordres. For en virksomhedsportefølje eller et offentligt program er disciplinen det, der lader jer forsvare sekvenseringsbeslutninger over for interessenter, der hver tror, deres initiativ bør komme først, fordi rækkefølgen hviler på angivet værdi frem for politik.
Hvem genprognosticerer, hvor ofte, og hvem er ansvarlig for at handle, når prognosen flytter sig? En forudsigelse lavet én gang ved kickoff og aldrig gensyn er pynt, og de dyreste glidninger er dem, en levende prognose ville have vist måneder før, deadline gjorde dem uigendrivelige. For et stort team er fejlen sjældent fraværet af data og som regel fraværet af en stående kadence og en navngiven ejer: gennemløb driver, afslutningsdatofordelingen skifter til højre, og ingen, hvis job det er at bemærke det, kigger. Tag jeres faktiske genprognoserytme (eller indrøm, at der ingen er), sidste gang en prognose ændrede en beslutning, og den drift, I har set, siden den nuværende forpligtelse blev sat, med. Det modstridende hensyn er prognosetræthed, da for støjende genprognosticering inviterer til thrash og eroderer tillid, så aftal et fornuftigt interval og en tærskel, der udløser eskalering, frem for at reagere på hvert vrid. I virksomheds- og offentlige sammenhænge så bind dette til tilsyn: orientér styringsorganer med det opdaterede sandsynlighedsinterval efter en fast tidsplan, så en glidning dukker op som en styret genprognose, ledere kan handle på, frem for en overraskelse afsløret ved milepælen.

Sektorperspektiv

Startup. Spring estimeringsceremonien næsten helt over. Skær arbejde i en-til-to-dages stykker, tæl hvad I færdiggør hver uge, og angiv grundlæggere og investorer et snævrende interval frem for en heroisk enkeltdato. Jeres historik er kort og jeres proces er flygtig, så støt jer til usikkerhedskeglen som en ærlig forklaring frem for en undskyldning, og genprognosticér hver fredag, efterhånden som billedet skærpes.

Lille virksomhed. I har ingen estimeringsspecialist og ingen appetit på størrelsesmøder, så lad de værktøjer, I allerede kører, gøre arbejdet: de fleste opgavesporere eksponerer gennemløb gratis, og en let prognose derfra slår en gættet deadline. Modstå trangen til at købe tung planlægningssoftware, I ikke kan bemande; en simpel ugentlig optælling af gennemførte poster og et klart interval besvarer “hvornår er det færdigt” godt nok til de forpligtelser, I faktisk giver kunder.

Stor virksomhed. Problemet er ensartethed på tværs af mange teams, der finansierer en portefølje mod en årlig kapitalcyklus (kapitel 10.1). Standardisér på intervaller med konfidensniveauer frem for enkeltdatoer, kræv referenceklassesammenligninger for store programmer, og rejs flowmålinger, så gæt viger for gennemløbsbaserede prognoser inden for et kvartal. Styr estimering som en fælles praksis med klare definitioner af estimat, mål og forpligtelse, så et tal produceret i én division betyder det samme, når det når bestyrelsen.

Offentlig sektor. Indkøbsregler og offentlig ansvarlighed former alt. En misset offentlig dato bliver en overskrift og et revisionsfund, så foretræk modulære, increment-finansierede kontrakter frem for en enkelt fastpris-, fastomfangsforpligtelse forankret til en fjern milepæl. Orientér tilsynsorganer med probabilistiske prognoser og referenceklassedokumentation i almindeligt sprog, offentliggør konfidensniveauer ærligt, og lad demonstrerede fungerende increments blive den dokumentation, offentligheden og revisorer stoler på, frem for en leverandørs underskrift på en optimistisk plan.

Eksempler

Startup. Et startup på ni personer, der forbereder sin Series A-demo, skal vide, om en nøgleintegration vil være klar. I stedet for at lade grundlæggerne love investorer en dato angiver lederen et estimat som et interval og forklarer usikkerhedskeglen bag. Teamet har lukket fem til ni efterslædspunkter om ugen, så de kører en hurtig Monte Carlo-prognose på det resterende arbejde og rapporterer “80 % sandsynligt til tredje uge i kvartalet, lige odds en uge tidligere.” De skærer integrationen i to-dages stykker, så intet enkelt estimat betyder meget, sekvenserer efter forsinkelsesomkostning for at bygge den investor-synlige sti først og genprognosticerer hver fredag. Investorer får en ærlig, snævrende projektion i stedet for et selvsikkert tal, der ville være gledet.

Stor virksomhed. En detailhandler, der erstatter sin ordrestyringsplatform, skal finansiere programmet gennem en årlig kapitalcyklus, der kræver et tal. Programkontoret modstår trangen til at forsvare den pæne bottom-up-plan og bygger i stedet en referenceklasse af tre sammenlignelige platformserstatninger, to interne og én offentligt dokumenteret, som overskred deres oprindelige estimater med 50 % til 80 %. De finansierer mod udefrakommende-perspektiv-tallet, udtrykker tidsplanen som et sandsynlighedsinterval frem for en fast go-live og rejser flowmålinger fra det første leverende team, så gættet inden for et kvartal erstattes af en gennemløbsbaseret prognose, der opdateres månedligt. Da ét spor løber varmt, viser genprognosen det tidligt, og ledelsen rebalancerer frem for at opdage glidningen ved deadline.

Offentlig sektor. Et agentur, der moderniserer et ydelsessystem, opererer under bevillinger og offentlig granskning, hvor en misset offentlig dato er en overskrift. I stedet for en enkelt fastpris-, fastomfangskontrakt forankret til én fjern milepæl indkøber det modulære increments og forpligter sig offentligt på en værdifuld kerne leveret tidligt, med senere omfang udtrykt som et finansieret interval frem for et løfte. Programledere orienterer tilsynsorganer med probabilistiske prognoser og referenceklassesammenligninger og forklarer konfidensniveauer i almindeligt sprog, så et “70 % til september” forstås som netop det. Demonstrerede fungerende increments bliver den dokumentation, offentligheden stoler på, hvilket er sundere end ethvert estimat, en leverandør kunne underskrive.

Business case: motivation, ROI og TCO

Afkastet af ærlig estimering og prognose domineres af undgået katastrofe. Store softwareindsatser overskrider eller fejler langt oftere, end de rammer en oprindelig fast plan, og tabene akkumulerer: sunket omkostning, forgået værdi ved sen levering, nødforbrug for at komme sig og den erosion af tillid, der følger efter et brudt offentligt løfte. Praksisserne her (at adskille estimat fra forpligtelse, at prognosticere ud fra reelt gennemløb, at tage udefrakommende perspektiv på store programmer) er dem, der flytter et program af den fiaskokurve. I køber ikke en mere nøjagtig krystalkugle. I køber tidligere, sandere information om, hvor I står, hvilket lader jer rette, mens rettelse stadig er billig.

Med hensyn til samlet ejeromkostning sænker skiftet fra estimeringsceremoni til målt prognose som regel omkostningen frem for at hæve den. Omstændelig estimering på forhånd er dyr at producere og henfalder i det øjeblik, arbejdet begynder, mens en gennemløbsbaseret prognose er næsten gratis, når jeres leveringspipeline udsender dataene. Begge yderpunkter koster penge: overestimering (endeløse størrelsesmøder, der producerer præcision, ingen bruger) og underprognose (at forpligte sig blindt og betale for overskridelsen senere). For at fremlægge sagen for ledelsen så stil den fuldt belastede omkostning ved jeres seneste større overskridelse ved siden af de næsten nul omkostninger ved at følge gennemløb og angive intervaller, og vis, hvordan en udefrakommende-perspektiv-prognose ville have sat en finansierbar forventning fra begyndelsen.

Anti-mønstre og faldgruber

Enkeltdatoforpligtelser: et interval kollapset til ét tal og så forsvaret ud over dokumentationen.
Estimatvask: et håbefuldt gæt sendt op ad kæden, til det hærder til et kontraktligt løfte.
Velocity som tidsplansmotor: at gange story points med velocity for at fremstille en præcis dato.
Polstring på fornemmelse: et andet gæt stablet oven på det første, forhandlet væk under pres.
Kun indre perspektiv: at stole på en frisk bottom-up-plan, mens man ignorerer, hvad lignende programmer faktisk tog.
At estimere alt: at størrelsesbedømme små, ensartede skiver, hvis individuelle estimater ikke ændrer nogen beslutning.
Frosne prognoser: en forudsigelse lavet én gang ved kickoff og aldrig opdateret, efterhånden som virkeligheden ankommer.
Præcisionsteater: at angive timer med to decimaler ved usikkerhedskeglens brede munding.

Modenhedsmodel

Niveau 1, Opstart: Estimater er enkeltdatoer produceret af mavefornemmelse og behandlet som løfter; ingen skelnen mellem estimat, mål og forpligtelse; prognose er reaktiv og ad hoc; overskridelser overrasker alle og bebrejdes teamet.
Niveau 2, Udvikling: Noget struktureret estimering findes (dekomposition, story points, trepunktstal), men praksis varierer team for team; estimater er stadig mest enkelte tal; velocity bruges til at projicere datoer; prognoser laves én gang ved kickoff og gensyn sjældent.
Niveau 3, Standardisering: En dokumenteret standard er håndhævet på tværs af organisationen: estimater udtrykkes som intervaller med angivet usikkerhed, estimat, mål og forpligtelse holdes adskilt ved definition, teams følger gennemløb og genprognosticerer efter en fast kadence, og store programmer skal bruge referenceklassesammenligninger.
Niveau 4, Styring: Praksissen måles og styres med data. Prognosenøjagtighed følges mod faktiske udfald, og kalibrering tjekkes, så I kan sige, om jeres “80 % til”-datoer faktisk lander otte gange ud af ti; gennemløbs- og gennemløbstidsbaselines vedligeholdes; forsinkelsesomkostning kvantificeres; prognosedrift overvåges mod tærskler og udløser eskalering; forpligtelser gives mod dokumentation frem for optimisme.
Niveau 5, Orkestrering: Probabilistisk prognose fra flowdata er kontinuerlig og betroet, fordi kalibreringshistorikken har bevist den ærlig; forpligtelser er bevidste beslutninger, der vejer konfidens mod omkostning; arbejde skæres småt nok til, at estimering er minimal, og forsinkelsesomkostning driver rækkefølgen; estimering er integreret med porteføljefinansiering og risikoplanlægning, og organisationen omafgrænser og rebalancerer rutinemæssigt, efterhånden som prognoser flytter sig, og tilpasser planen til dokumentation frem for at forsvare det oprindelige tal.

Idéer til drøftelse

Hvad ville ændre sig i jeres organisation, hvis hvert estimat skulle forlade teamet som et interval med et konfidensniveau, og enkeltdatoer var forbudt?
Hvor bruger I indsats på at estimere arbejde, der allerede er småt og ensartet nok til at prognosticere ved optælling?
Hvis I fodrede de seneste to kvartalers gennemløb ind i en Monte Carlo-simulering, ville prognosen så stemme overens med de datoer, I faktisk forpligtede jer på?
For jeres største program, hvad er den ærlige referenceklasse, og hvor slemt modsiger baseraten jeres nuværende plan?
Hvordan afgør jeres team rækkefølge i dag, og ville en eksplicit ordning efter forsinkelsesomkostning ændre, hvad I bygger næste gang?
Når en forpligtelse accepteres i jeres organisation, registreres usikkerheden så som en del af beslutningen, eller forsvinder den i det øjeblik, datoen skrives ned?

Vigtigste pointer

Hold estimatet, målet og forpligtelsen adskilt; at lade dem falde sammen er, hvordan projekter begynder at lyve for sig selv.
Estimater er systematisk forkerte i kendte retninger: usikkerhedskeglen udvider tidligt arbejde, og planlægningsfejlslutningen gør optimisme til standard.
Foretræk probabilistisk prognose ud fra målt gennemløb frem for friske gæt; angiv intervaller og konfidensniveauer, og genprognosticér kontinuerligt.
Tag udefrakommende perspektiv med referenceklasseprognose på store programmer, hvor optimisme er dyrest (kapitel 10.1).
Skær småt, så individuelle estimater holder op med at have betydning, og sekvensér efter forsinkelsesomkostning frem for mavefornemmelse.
Estimér kun, når det ændrer en beslutning; ellers er det spild. Se kapitel 10.6 (projektstyring), 11.2 (levering), 11.3 (køteori) og 1.5 (beslutningstagning og styring).

Referencer og videre læsning

Steve McConnell, Software Estimation: Demystifying the Black Art.
Daniel Vacanti, Actionable Agile Metrics for Predictability and When Will It Be Done? (probabilistic forecasting from flow data).
Troy Magennis, Forecasting and Simulating Software Development Projects (Monte Carlo methods).
Bent Flyvbjerg and Dan Gardner, How Big Things Get Done (reference class forecasting and megaprojects).
Daniel Kahneman, Thinking, Fast and Slow (the planning fallacy and the outside view).
Donald Reinertsen, The Principles of Product Development Flow (cost of delay and queue economics).
Vasco Duarte, NoEstimates: How to Measure Project Progress Without Estimating.
Frederick Brooks, The Mythical Man-Month (why software schedules go wrong).
Todd Little, “Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty” (IEEE Software, 2006).