10.15 Uppskattning och prognoser

Översikt och motivation

Varje programvaruteam får samma fråga: när blir det klart? Bakom den frågan sitter uppskattning av programvaruutvecklingsinsats, praxisen att förutsäga hur mycket arbete något kommer att ta innan ni har gjort det. Det är en av de svåraste sakerna vi gör, och en av de lättaste att göra dåligt. Problemet är att programvara är upptäcktsarbete. Ni bygger något som aldrig tidigare funnits, och mycket av det ni kommer att lära er om problemet blir synligt först medan ni bygger. Att förutsäga insatsen för att lära sig är genuint annorlunda än att förutsäga insatsen för att upprepa en känd uppgift.

Varför behandla detta som en egen disciplin snarare än en hörna av projektledning (kapitel 10.6)? För att felen är så konsekventa och så dyra. Team förbinder sig rutinmässigt till enskilda datum de saknar belägg för och försvarar sedan dessa datum långt förbi punkten där verkligheten motsagt dem. Ledare förväxlar ett estimat med ett löfte. Avtal fryser ett tal producerat på en eftermiddag och håller människor till det i ett år. Resultatet är sen leverans, urholkat förtroende och en kultur där ingen säger vad de faktiskt tror. Att få detta rätt handlar mindre om bättre matematik och mer om ärlighet: att skilja det ni vet från det ni hoppas och att kommunicera osäkerhet som osäkerhet.

Insatserna stiger kraftigt i företags- och myndighetsmiljöer. Företag finansierar portföljer av sammanflätade initiativ mot årliga budgetar och förväntar sig fasta tal för att fördela kapital (kapitel 10.1). Myndigheter gör offentliga åtaganden under anslagsregler, skriver under fastprisavtal och svarar inför lagstiftare när ett datum glider. I båda världarna är trycket att producera ett säkert enskilt tal enormt, och den djupa osäkerhet som gör det talet opålitligt försvinner inte för att någon viktig vill ha säkerhet. Det här kapitlet argumenterar för en annan hållning: uppskatta när det hjälper er att besluta, prognostisera med belägg snarare än optimism och tala sanning om intervallet.

Nyckelprinciper

Ett estimat är en förutsägelse, inte ett löfte. Håll det skilt från mål och åtaganden.
Osäkerhet är verklig, så uttryck den. Ett intervall med en sannolikhet slår ett falskt enskilt datum.
Det förflutna förutsäger framtiden bättre än optimism. Föredra uppmätt historik framför färska gissningar.
Bryt ner för att förstå, prognostisera för att förbinda sig. Små skivor minskar både risk och behovet att uppskatta.
Ta utifrånperspektivet. Jämför med liknande tidigare satsningar innan ni litar på er insideberättelse.
Prognostisera om kontinuerligt. En förutsägelse gjord en gång och aldrig uppdaterad är dekoration.
Uppskatta bara när svaret ändrar ett beslut. Annars är det slöseri.

Rekommendationer

Skilj estimatet, målet och åtagandet åt

Det enskilt mest användbara draget i hela det här kapitlet kostar ingenting: håll tre idéer åtskilda. Ett estimat är er ärliga förutsägelse av hur lång tid något tar, med dess osäkerhet fäst. Ett mål är ett affärsmål ni gärna skulle nå, som en mässlansering eller en regulatorisk frist. Ett åtagande är ett löfte ni ger någon annan som ni avser hålla. Detta är tre olika saker, och att slå ihop dem är hur projekt börjar ljuga för sig själva. När en ledare hör “ungefär tre till fem månader” och skriver ned “tre månader”, och säljteamet lovar en kund “tolv veckor”, har ett estimat i tysthet blivit ett åtagande utan att någon beslutat acceptera risken.

Säg vilket ni ger, varje gång. Om ni får frågan om ett datum, svara med ett estimat uttryckt som ett intervall, låt sedan verksamheten sätta ett mål mot det och avgöra, medvetet, vad den ska förbinda sig till. Ett åtagande bör vara ett val gjort med öppna ögon, där estimatets osäkerhet vägs mot kostnaden för att missa. Den disciplinen kopplar direkt till hur er organisation fattar och registrerar beslut (kapitel 1.5): ett åtagande är ett beslut, och det förtjänar ett besluts stringens snarare än ett nick i korridoren.

Förstå varför estimat blir fel, och i vilken riktning

Programvaruestimat är inte slumpmässigt fel. De är fel på förutsägbara, systematiska sätt, och att känna mönstret låter er korrigera för det. Tidigt i varje satsning sitter ni inuti osäkerhetskonen: i början kan ert estimat lätt vara fel med en faktor fyra åt endera hållet, och intervallet smalnar först när ni bygger och lär er. Att förbinda sig till ett precist tal vid konens breda mynning är att förbinda sig till en siffra ni ännu inte kan stödja.

Ovanpå den strukturella osäkerheten ligger en mänsklig bias. Planeringsfelslutet är vår pålitliga tendens att underskatta tiden, kostnaden och risken i våra egna planer medan vi föreställer oss bästa fallet. Vi ser den glada vägen framför oss, glömmer avbrotten och integrationsöverraskningarna och sjukdagarna och producerar ett tal som förutsätter att inget går fel. Buffert är det vanliga defensiva svaret, men buffert tillagd på känsla är bara en andra gissning ovanpå den första, och den förhandlas bort i samma ögonblick scheman stramas åt. Botemedlet är inte mer viljestyrka. Det är metod. Basera förutsägelser på vad liknande arbete faktiskt tog, inte på hur det här arbetet känns inifrån.

Använd nedbrytning och expertomdöme, och känn deras gränser

Arbetshästteknikerna är värda att känna till och värda att avgränsa. Nedbrytning bryter ned en stor leverans i mindre delar ni kan resonera om och rullar sedan upp delarna. Den hjälper eftersom människor uppskattar små, bekanta saker långt bättre än stora, vaga, och eftersom att summera många oberoende poster låter vissa överskattningar ta ut vissa underskattningar. Dess gräns är att nedbrytning missar arbetet mellan lådorna: integration, samordning och de uppgifter ni inte tänkte lista. Expertomdöme och estimering genom analogi (“det här är som rapportmodulen vi byggde förra året, som tog två månader”) är snabba och ofta förvånansvärt bra, men de ärver estimatorns optimism och blinda fläckar.

För allt ni måste sätta ett tal på, föredra trepunktsestimering, som ber om ett optimistiskt, ett troligast och ett pessimistiskt tal och kombinerar dem, ofta som PERT:s viktade medelvärde (optimistiskt plus fyra gånger troligast plus pessimistiskt, delat med sex). Värdet är inte den precisa formeln. Det är att trepunktsestimering tvingar er att säga er osäkerhet högt och producerar ett intervall i stället för en falsk punkt. Relativa storleksmetoder som storypoäng och t-shirtstorlekar (liten, medel, stor, extra stor) kringgår fällan att förutsäga exakta timmar genom att jämföra poster med varandra. De fungerar bra för ordning och grov kapacitet, men behandla dem som indata till en prognos, inte som valuta. Poäng är inte timmar, och att multiplicera velocity med poäng för att producera ett datum återinför varje problem relativ storleksbedömning var tänkt att undvika.

Prognostisera probabilistiskt från er egen flödesdata

Här är skiftet som ändrar allt: sluta be människor gissa hur lång tid arbete tar och börja mäta hur fort ert team faktiskt blir klart med arbete. Er leveranspipeline (kapitel 11.2) producerar redan den data ni behöver. Om ni följer genomströmning, antalet poster ert team slutför per vecka, kan ni prognostisera framtiden från det förflutna i stället för från hopp. Ett team som har stängt sex till elva poster i veckan de senaste tre månaderna kommer med hög sannolikhet att ta ungefär fyra till sju veckor på sig för fyrtio återstående poster. Den prognosen vilar på belägg, och den uppdaterar sig själv varje vecka när ny data anländer.

Den rigorösa versionen kör en Monte Carlo-metod-simulering: dra urval ur er historiska veckovisa genomströmning tusentals gånger för att bygga en fördelning av möjliga slutdatum och läs sedan av svaret som en sannolikhet. “Vi är 85 % sannolika att bli klara senast 14 mars, och 50 % sannolika senast 28 februari” är ett vitt mer användbart och mer ärligt uttalande än “det blir klart 1 mars.” Ansatsen kopplar direkt till köteori (kapitel 11.3): ledtid är lika med pågående arbete delat med genomströmning, så samma flödesmått som styr hur arbete rör sig styr också när det kommer fram. Probabilistisk prognostisering behöver historik och en rimligt stabil process, vilket är just varför den belönar team som håller arbetet litet och flödet jämnt. Den tar också i tysthet bort det mesta av estimeringsceremonin, eftersom ni inte längre behöver storleksätta varje post för att veta när partiet landar.

Ta utifrånperspektivet för stora program

För stora, långa, dyra program kan enskilda estimat och till och med flödesprognoser vilseleda, eftersom ett nytt program ännu inte har någon genomströmningshistorik och dess insideberättelse är just där planeringsfelslutet bits hårdast. Motgiftet är referensklassprognostisering: hitta en referensklass av liknande slutförda satsningar, titta på hur lång tid och hur mycket de faktiskt tog och placera ert program i den fördelningen innan ni litar på er egen nedifrån-och-upp-plan. Om jämförbara plattformsersättningar på ert företag har överskridit sina inledande estimat med 60 % i genomsnitt är det talet bättre belägg om ert än den prydliga plan ert team just satte ihop. Utifrånperspektivet känns nedslående, och det är just dess värde: det motverkar den optimism varje färsk plan bär. Använd det för portföljfinansiering och budgetering av megaprogram (kapitel 10.1), där kostnaden för ett systematiskt överskridande mäts i miljoner och i trovärdighet.

Uppskatta mindre genom att skiva mindre och sekvensera efter fördröjningskostnad

Ibland är rätt mängd uppskattning nästan ingen. Argumentet #NoEstimates, i sin rimliga kärna, observerar att om ni skivar arbetet i bitar tillräckligt små för att var och en tar en eller två dagar, slutar estimatet av en enskild bit att spela roll. Ni räknar helt enkelt genomströmning och prognostiserar utifrån räkningen. När skivor är enhetliga och små är genomarbetad storleksbedömning slöseri: den förbrukar insats för att producera precision som prognosen inte behöver. Det är inget argument mot att tänka framåt. Det är ett argument för att göra enskilda förutsägelser billiga genom att göra enskilda bitar små.

Det som fortfarande behöver ett beslut är ordning. När ni inte kan göra allt på en gång, sekvensera efter fördröjningskostnad: det värde ni förlorar för varje tidsenhet ett givet arbete är sent. En funktion som låser upp ett stort avtal nästa kvartal har en hög fördröjningskostnad och bör hoppa före ett trevligt-att-ha utan någon, även om det trevliga-att-ha är lättare. Att väga fördröjningskostnad mot insats (heuristiken “viktat kortaste jobb först” från lean-tänkande) talar om vad ni ska göra härnäst långt mer pålitligt än en backlogg sorterad på magkänsla. Lägg märke till att detta omformulerar hela samtalet: i stället för “när blir allt klart”, som inbjuder till falsk precision, frågar ni “vad är det mest värdefulla att bli klar med härnäst”, vilket ni faktiskt kan besvara.

Avvägningar: för- och nackdelar

Tillvägagångssätt	Fördelar	Nackdelar
Estimat med ett enda datum	Enkelt. Det intressenter ber om	Precist fel. Döljer risk. Blir ett oavsiktligt åtagande
Trepunkts-/PERT-estimat	Tvingar osäkerhet i dagen. Billigt	Fortfarande en gissning. Formeln antyder falsk stringens
Storypoäng / t-shirtstorlekar	Snabbt. Bra för ordning och grov kapacitet	Inte timmar. Velocity-matematik smyger in enskilda datum igen
Probabilistisk flödesprognos	Belägg-baserad. Självuppdaterande. Ärliga intervall	Behöver historik och stabilt flöde. Ser mindre “säker” ut
Referensklassprognostisering	Korrigerar optimism på stora program	Behöver jämförbara tidigare satsningar. Nedslående att höra
#NoEstimates (små skivor)	Tar bort slöseri. Prognostisera genom att räkna	Kräver disciplinerad skivning. Oroande för finansiärer som vill ha ett tal

Den centrala spänningen är den säkerhet människor vill ha mot den ärlighet arbetet kräver. Finansiärer, chefer, avtal och lagstiftare ber om ett fast enskilt datum eftersom ett enda datum är lätt att budgetera, lova och försvara. Programvara stöder sällan ett. Lös spänningen inte genom att fabricera säkerhet och inte genom att vägra svara, utan genom att svara i sannolikhetens valuta: ett intervall med tillförlitlighetsnivåer, omprognostiserat när belägg anländer. Para det med små skivor så att tidiga, verkliga leveranser ersätter avlägsna, imaginära som det människor litar på. Ett demonstrerat inkrement är värt mer än något estimat.

Frågor att diskutera med ditt team

När någon ber er om ett datum, ger ni ett estimat, ett mål eller ett åtagande, och vet alla i rummet vilket? Det här är frågan som förhindrar mest skada för minst insats. I de flesta organisationer kollapsar dessa tre till ett tal i samma ögonblick det lämnar teamets mun, och ingen beslutade acceptera risken att en förutsägelse blev ett löfte. Ta med ett verkligt exempel: ta er senaste bundna frist och spåra den bakåt till samtalet där den först yttrades och fråga om den någonsin var något annat än en hoppfull gissning i kostym. Svaret bör ändra ert språk permanent, så att estimat går ut som intervall, mål namnges som affärsönskningar och åtaganden görs medvetet med osäkerheten vägd och registrerad som ett beslut (kapitel 1.5). Om ert team inte kan peka på var ett åtagande medvetet accepterades ger ni löften av misstag.
Kunde ni prognostisera er nästa release från uppmätt genomströmning i stället för från färska estimat, och vad hindrar er? De flesta team har redan datan för att besvara “när blir det klart” empiriskt, liggande oanvänd i verktyget som följer deras arbete. Om ni vet hur många poster ert team har slutfört per vecka det senaste kvartalet kan ni simulera en fördelning av slutdatum och ange en sannolikhet snarare än en önskan. Ta med er faktiska genomströmningshistorik och ert antal återstående poster och jämför den flödesbaserade prognosen mot vilket datum teamet uppskattade på känsla. Gapet är vanligen lärorikt. Om hindret är att era poster är vilt olika stora eller att ert flöde är oregelbundet är det i sig fyndet, eftersom instabilt flöde är ett leveransproblem värt att rätta oavsett (kapitel 11.2, 11.3). Att gå från uppskattning till mätning är ofta mindre en verktygsändring än ett beslut att lita på sin egen historik framför sin optimism.
För ert största nuvarande program, har ni tagit utifrånperspektivet, eller bara byggt en insideplan? Stora program är där optimism ackumuleras till dyra överskridanden, och där en säker nedifrån-och-upp-plan är mest förledande och minst pålitlig. Disciplinen är att namnge en referensklass av liknande slutförda satsningar inom eller utanför er organisation, ta reda på vad de faktiskt kostade och hur lång tid de faktiskt tog och placera ert program ärligt i den fördelningen innan ni försvarar era egna tal. Ta med datan: hur har jämförbara initiativ här överskridit sina första estimat, och antar er nuvarande plan i tysthet att ni kommer att slå var och en av dem? Om den gör det satsar ni på att vara exceptionella, en satsning som grundfrekvenserna pålitligt förlorar. Utifrånperspektivet kommer att göra er prognos mindre smickrande och långt mer försvarbar inför de finansiärer och revisorer som kommer att minnas talet ni gav (kapitel 10.1).
När en finansiär, ett avtal eller en lagstiftare kräver ett fast datum, hur svarar ni utan att ljuga eller vägra? Det är här trycket är hårdast och där ärliga team oftast ger efter, eftersom “70 % sannolikt senast september” låter undvikande bredvid en konkurrents säkra “september.” För en stor organisation multipliceras insatserna: ett fast datum sprider sig in i budgetar, beroende program och offentliga löften, så ett tal valt för komfort blir en systemisk skuld i samma ögonblick det glider. Ta med språket ni faktiskt planerar använda, ett genomarbetat exempel på ett intervall med tillförlitlighetsnivåer och ett litet tidigt inkrement ni kan förbinda er fast till medan senare omfattning lämnas som ett finansierat intervall. Den konkurrerande hänsynen är verklig, eftersom vissa frister (en regulatorisk övergång, en mässlansering) är genuint fasta, och det rätta draget där är att fixera datumet och böja omfattningen snarare än att låtsas att insatsen är säker. I företags- och myndighetssammanhang, knyt detta till hur avtalet utformas: ett modulärt, inkrementfinansierat avtal låter er förbinda er ärligt till en värdefull kärna, medan ett enda fastpris-, fastomfattningsavtal förankrat vid en avlägsen milstolpe tvingar fram just den falska säkerhet som producerar överskridandet och rubriken.
Hur avgör ert team vad som ska byggas härnäst, och skulle uttrycklig sekvensering efter fördröjningskostnad ändra ordningen? De flesta backloggar ordnas efter en blandning av magkänsla, den som ropade högst och grov insats, vilket i tysthet optimerar för enkla vinster snarare än värdefulla. Fördröjningskostnad, det värde ni förlorar för varje tidsenhet ett arbete är sent, omformulerar frågan från “när blir allt klart” till “vad är det mest värdefulla att bli klar med härnäst”, vilket ni faktiskt kan besvara med belägg. Ta med tre eller fyra verkliga backloggposter med ett ärligt estimat av det värde var och en låser upp och när det värdet förfaller och rangordna dem sedan efter förlorat värde per vecka mot insats och jämför den ordningen med er nuvarande plan. Omordningen är vanligen överraskande och svår att argumentera mot. Den konkurrerande hänsynen är att fördröjningskostnad i sig är ett estimat och kan manipuleras av den som vill ha sin post först, så namnge vem som äger talen och hur de utmanas. För en företagsportfölj eller ett myndighetsprogram är den här disciplinen det som låter er försvara sekvenseringsbeslut inför intressenter som var och en tror att deras initiativ borde komma först, eftersom ordningen vilar på angivet värde snarare än politik.
Vem prognostiserar om, hur ofta, och vem är ansvarig för att agera när prognosen rör sig? En förutsägelse gjord en gång vid kickoff och aldrig omvärderad är dekoration, och de dyraste glidningarna är de som en levande prognos hade visat månader innan fristen gjorde dem obestridliga. För ett stort team är felet sällan frånvaron av data och vanligen frånvaron av en stående takt och en namngiven ägare: genomströmningen driftar, fördelningen av slutdatum skiftar åt höger och ingen vars jobb det är att märka tittar. Ta med er faktiska omprognostiseringsrytm (eller erkänn att ingen finns), senaste gången en prognos ändrade ett beslut och den drift ni har sett sedan det nuvarande åtagandet sattes. Den konkurrerande hänsynen är prognoströtthet, eftersom att prognostisera om för bullrigt inbjuder till tröskel och urholkar förtroende, så kom överens om ett förnuftigt intervall och en tröskel som utlöser eskalering snarare än att reagera på varje vingling. I företags- och myndighetssammanhang, koppla detta till tillsyn: informera styrningsorgan med det uppdaterade sannolikhetsintervallet enligt ett fast schema, så att en glidning visar sig som en hanterad omprognos ledare kan agera på snarare än en överraskning avslöjad vid milstolpen.

Sektorsperspektiv

Startup. Hoppa över estimeringsceremonin nästan helt. Skiva arbetet i bitar på en till två dagar, räkna vad ni slutför varje vecka och ge grundare och investerare ett smalnande intervall snarare än ett heroiskt enskilt datum. Din historik är kort och din process volatil, så lita på osäkerhetskonen som en ärlig förklaring snarare än en ursäkt och prognostisera om varje fredag när bilden skärps.

Småföretag. Du har ingen estimeringsspecialist och ingen aptit för storleksmöten, så låt verktygen du redan kör göra jobbet: de flesta uppgiftsföljare exponerar genomströmning gratis, och en lättviktig prognos från det slår ett gissat datum. Stå emot lusten att köpa tung planeringsprogramvara du inte kan bemanna. En enkel veckovis räkning av slutförda poster och ett enkelt intervall besvarar “när blir det klart” tillräckligt väl för de åtaganden du faktiskt gör mot kunder.

Storföretag. Problemet är konsekvens över många team som finansierar en portfölj mot en årlig kapitalcykel (kapitel 10.1). Standardisera på intervall med tillförlitlighetsnivåer snarare än enskilda datum, kräv referensklassjämförelser för stora program och sätt upp flödesmått så att gissningar viker för genomströmningsbaserade prognoser inom ett kvartal. Styr uppskattning som en gemensam praxis med tydliga definitioner av estimat, mål och åtagande, så att ett tal producerat i en division betyder detsamma när det når styrelsen.

Offentlig sektor. Upphandlingsregler och offentlig ansvarsskyldighet formar allt. Ett missat offentligt datum blir en rubrik och en revisionsanmärkning, så föredra modulära, inkrementfinansierade avtal framför ett enda fastpris-, fastomfattningsåtagande förankrat vid en avlägsen milstolpe. Informera tillsynsorgan med probabilistiska prognoser och referensklassbelägg på klarspråk, publicera tillförlitlighetsnivåer ärligt och låt demonstrerade fungerande inkrement bli det belägg allmänheten och revisorer litar på snarare än en leverantörs namnteckning på en optimistisk plan.

Exempel

Startup. Ett startup på nio personer som förbereder sin Serie A-demo behöver veta om en nyckelintegration blir klar. I stället för att låta grundarna lova investerarna ett datum anger ledaren ett estimat som ett intervall och förklarar osäkerhetskonen bakom det. Teamet har stängt fem till nio backloggposter i veckan, så de kör en snabb Monte Carlo-prognos på det återstående arbetet och rapporterar “80 % sannolikt senast tredje veckan i kvartalet, jämna odds en vecka tidigare.” De skivar integrationen i tvådagarsbitar så att inget enskilt estimat spelar stor roll, sekvenserar efter fördröjningskostnad för att bygga den för investerare synliga vägen först och prognostiserar om varje fredag. Investerarna får en ärlig, smalnande projektion i stället för ett säkert tal som skulle ha glidit.

Storföretag. En detaljhandlare som ersätter sin orderhanteringsplattform måste finansiera programmet genom en årlig kapitalcykel som kräver ett tal. Programkontoret står emot lusten att försvara den prydliga nedifrån-och-upp-planen och bygger i stället en referensklass av tre jämförbara plattformsersättningar, två interna och en offentligt dokumenterad, som överskred sina inledande estimat med 50 % till 80 %. De finansierar mot utifrånperspektivets siffra, uttrycker schemat som ett sannolikhetsintervall snarare än en fast driftsättning och sätter upp flödesmått från första leveransteamet så att gissningen inom ett kvartal ersätts av en genomströmningsbaserad prognos som uppdateras varje månad. När ett spår går hett visar omprognosen det tidigt, och ledningen balanserar om snarare än att upptäcka glidningen vid fristen.

Offentlig sektor. En myndighet som moderniserar ett bidragssystem verkar under anslag och offentlig granskning, där ett missat offentligt datum är en rubrik. I stället för ett enda fastpris-, fastomfattningsavtal förankrat vid en avlägsen milstolpe upphandlar den modulära inkrement och förbinder sig offentligt till en värdefull kärna levererad tidigt, med senare omfattning uttryckt som ett finansierat intervall snarare än ett löfte. Programledare informerar tillsynsorgan med probabilistiska prognoser och referensklassjämförelser och förklarar tillförlitlighetsnivåer på klarspråk, så att ett “70 % senast september” förstås som precis det. Demonstrerade fungerande inkrement blir det belägg allmänheten litar på, vilket är sundare än något estimat en leverantör kunde skriva under.

Affärsnytta: motiv, ROI och TCO

Avkastningen på ärlig uppskattning och prognostisering domineras av undvikna katastrofer. Stora programvarusatsningar överskrider eller misslyckas långt oftare än de når en ursprunglig fast plan, och förlusterna ackumuleras: bunden kostnad, utebliven nytta från sen leverans, akuta utgifter för att återhämta sig och det urholkade förtroende som följer på ett brutet offentligt åtagande. Praxisen här (att skilja estimat från åtagande, att prognostisera från verklig genomströmning, att ta utifrånperspektivet på stora program) är den som flyttar ett program av den misslyckandekurvan. Ni köper inte en mer exakt kristallkula. Ni köper tidigare, sannare information om var ni står, vilket låter er korrigera medan korrigering fortfarande är billig.

Vad gäller total ägandekostnad sänker skiftet från estimeringsceremoni till uppmätt prognostisering vanligen kostnaden snarare än höjer den. Genomarbetad uppskattning i förväg är dyr att producera och förfaller i samma ögonblick arbetet börjar, medan en genomströmningsbaserad prognos är nästan gratis när er leveranspipeline väl sänder ut datan. Båda ytterligheterna kostar pengar: överuppskattning (ändlösa storleksmöten som producerar precision ingen använder) och underprognostisering (att förbinda sig blint och betala för överskridandet senare). Driv ärendet inför ledningen genom att ställa den fullt belastade kostnaden för ert senaste stora överskridande bredvid den nära noll-kostnaden för att följa genomströmning och ange intervall och visa hur en utifrånperspektivsprognos hade satt en finansierbar förväntan från början.

Antimönster och fallgropar

Åtaganden med ett enda datum: ett intervall kollapsat till ett tal och sedan försvarat förbi beläggen.
Estimattvätt: en hoppfull gissning skickad uppför kedjan tills den hårdnar till ett avtalsenligt löfte.
Velocity som schemamotor: att multiplicera storypoäng med velocity för att tillverka ett precist datum.
Buffert på känsla: en andra gissning staplad på den första, förhandlad bort under press.
Bara insidesyn: att lita på en färsk nedifrån-och-upp-plan medan man ignorerar vad liknande program faktiskt tog.
Att uppskatta allt: att storleksätta små, enhetliga skivor vars enskilda estimat inte ändrar något beslut.
Frusna prognoser: en förutsägelse gjord en gång vid kickoff och aldrig uppdaterad när verkligheten anländer.
Precisionsteater: att ange timmar med två decimaler vid osäkerhetskonens breda mynning.

Mognadsmodell

Nivå 1, Initiera: Estimat är enskilda datum producerade av magkänsla och behandlade som löften. Ingen skillnad mellan estimat, mål och åtagande. Prognostisering är reaktiv och ad hoc. Överskridanden överraskar alla och skylls på teamet.
Nivå 2, Utveckla: Viss strukturerad uppskattning finns (nedbrytning, storypoäng, trepunktstal), men praxis varierar från team till team. Estimat är fortfarande mestadels enskilda tal. Velocity används för att projicera datum. Prognoser görs en gång vid kickoff och omvärderas sällan.
Nivå 3, Standardisera: En dokumenterad standard upprätthålls i hela organisationen: estimat uttrycks som intervall med angiven osäkerhet, estimat, mål och åtagande hålls åtskilda genom definition, team följer genomströmning och prognostiserar om med en fast takt och stora program måste använda referensklassjämförelser.
Nivå 4, Hantera: Praxisen mäts och styrs med data. Prognosnoggrannhet följs mot faktiska utfall och kalibrering kontrolleras, så att ni kan säga om era “80 % senast”-datum faktiskt infaller åtta gånger av tio. Genomströmnings- och ledtidsutgångslägen underhålls. Fördröjningskostnad kvantifieras. Prognosdrift övervakas mot trösklar och utlöser eskalering. Åtaganden görs mot belägg snarare än optimism.
Nivå 5, Orkestrera: Probabilistisk prognostisering från flödesdata är kontinuerlig och betrodd eftersom kalibreringshistoriken har bevisat den ärlig. Åtaganden är medvetna beslut som väger tillförlitlighet mot kostnad. Arbete skivas tillräckligt litet för att uppskattning är minimal och fördröjningskostnad driver sekvens. Uppskattning är integrerad med portföljfinansiering och riskplanering, och organisationen avgränsar om och balanserar om rutinmässigt när prognoser rör sig och anpassar planen efter belägg snarare än försvarar det ursprungliga talet.

Idéer för diskussion

Vad skulle ändras i er organisation om varje estimat måste lämna teamet som ett intervall med en tillförlitlighetsnivå, och enskilda datum var förbjudna?
Var lägger ni insats på att uppskatta arbete som redan är litet och enhetligt nog att prognostisera genom att räkna?
Om ni matade in era två senaste kvartals genomströmning i en Monte Carlo-simulering, skulle prognosen stämma med de datum ni faktiskt förband er till?
För ert största program, vad är den ärliga referensklassen, och hur illa motsäger grundfrekvensen er nuvarande plan?
Hur avgör ert team sekvens i dag, och skulle uttrycklig ordning efter fördröjningskostnad ändra vad ni bygger härnäst?
När ett åtagande accepteras i er organisation, registreras osäkerheten som en del av beslutet, eller försvinner den i samma ögonblick datumet skrivs ned?

Viktigaste punkter

Håll estimatet, målet och åtagandet åtskilda. Att slå ihop dem är hur projekt börjar ljuga för sig själva.
Estimat är systematiskt fel i kända riktningar: osäkerhetskonen vidgar tidigt arbete, och planeringsfelslutet gör optimism till standard.
Föredra probabilistisk prognostisering från uppmätt genomströmning framför färska gissningar. Ange intervall och tillförlitlighetsnivåer och prognostisera om kontinuerligt.
Ta utifrånperspektivet med referensklassprognostisering på stora program, där optimism är dyrast (kapitel 10.1).
Skiva litet så att enskilda estimat slutar spela roll och sekvensera efter fördröjningskostnad snarare än magkänsla.
Uppskatta bara när det ändrar ett beslut. Annars är det slöseri. Se kapitel 10.6 (projektledning), 11.2 (leverans), 11.3 (köteori) och 1.5 (beslutsfattande och styrning).

Referenser och vidare 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).