Abstrakt Odhadování pracnosti softwaru patří k nejproblematičtějším disciplínám projektového řízení. Statistiky Standish Group dlouhodobě uvádějí, že pouze necelá třetina IT projektů končí v plánovaném termínu, průměrné překročení rozpočtu se pohybuje kolem 180 % a téměř pětina projektů je předčasně ukončena. Článek porovnává hodinové odhady s relativním odhadem ve Story Points, popisuje techniky jako Planning Poker, Reference Class Forecasting a Three-Point Estimation, představuje hnutí #NoEstimates a uvádí provozní metriky, které pomáhají odhady systematicky zlepšovat.
1. Proč jsou odhady systematicky nepřesné
Software je invisibilní produkt s nelineární komplexitou: malá změna v požadavku může znamenat zásadní přepracování kódu. Na úrovni jednotlivce působí psychologické zkreslení, na úrovni organizace pak tlak deadlinů a kultura, která trestá překročení místo toho, aby odměňovala přesnost.
Daniel Kahneman popsal v knize Thinking, Fast and Slow tzv. planning fallacy: lidé systematicky podceňují čas, náklady i rizika, protože si při odhadu představují optimistický scénář. K tomu se přidává optimism bias (focus na nejlepší případ), anchoring effect (první vyřčené číslo zakotvuje skupinu) a confirmation bias (hledání informací potvrzujících odhad).
Industriální data hovoří jasně: jen 29 % projektů je dokončeno včas, průměrné překročení nákladů činí 189 %, průměrné překročení harmonogramu 167 %, 19 % projektů je zrušeno. Tyto statistiky reflektují systémovou nepřesnost odhadovacího procesu, nikoli individuální selhání.
2. Hodinové odhady a jejich limity
Hodinový odhad působí důvěryhodně, protože hodina je přesná jednotka. Problém spočívá v nelinearitě: úkoly odhadnuté na 2 hodiny mají variabilitu kolem 10 %, úkoly na 8 hodin kolem 40 %, úkoly na 40 hodin kolem 80 % a více. Variabilita roste rychleji než lineárně s velikostí úlohy.
Druhým problémem je Parkinsonův zákon: práce se rozprostře do veškerého dostupného času. Třetí úskalí je commitment trap – odhad se mění v závazek, jehož nedodržení je penalizováno. Tým se brání paddingem (přidáním rezervy ke každému odhadu), čímž ztrácí výhody přesnějšího plánování.
Hodinové odhady fungují přiměřeně pouze pro úlohy do 4 hodin práce s jasným zadáním a známou technologií. Pro vše ostatní je metoda systematicky zavádějící.
3. Story Points jako relativní odhad
V roce 2005 popsal Mike Cohn v knize Agile Estimating and Planning princip relativního odhadování: nezáleží na tom, kolik hodin úkol trvá, ale jak je složitý oproti referenční úloze. Story Points jsou bezrozměrná jednotka složitosti, která agreguje pracnost, riziko a nejistotu.
Týmy obvykle používají Fibonacciho posloupnost (1, 2, 3, 5, 8, 13, 21) protože odráží rostoucí nejistotu u větších úloh – mezi 1 a 2 je rozdíl jasný, mezi 13 a 21 už hraje variabilita významnou roli a debata o detailech je ztrátou času.
Po pěti až šesti sprintech se velocity (počet bodů dokončených za sprint) stabilizuje s koeficientem variability typicky pod 15 %. Tým se 180 zbývajícími body a velocity 28 dokončí backlog s 50% pravděpodobností za 6 sprintů a s 95% pravděpodobností za 10 sprintů. Monte Carlo simulace nad historickými daty poskytují předpovědi s pravděpodobnostními intervaly, které jsou pro byznys hodnotnější než jediné číslo.
4. Planning Poker
Planning Poker je strukturovaná technika kolektivního odhadu. Každý člen týmu skrytě zvolí kartu s hodnotou Fibonacciho řady. Karty se odhalí současně, čímž se eliminuje anchor effect prvního vyřčeného odhadu. Pokud se odhady výrazně liší, nejvyšší a nejnižší hodnotitel vysvětlí svou úvahu. Po krátké diskuzi následuje další kolo. Konsensus zpravidla nastane do tří kol.
Skutečnou hodnotou metody není výsledné číslo, ale diskuze: odhalí, že tým rozumí požadavku různě. Příklad z praxe – story „integrace s platební bránou“ s odhady 3, 8, 5, 13 a 8. Junior viděl pouze API call, senior viděl error handling, webhooks a refundační logiku. Po vyjasnění Product Ownerem se konsensus ustálil na 8 bodech.
Doporučená pravidla: max 5 minut diskuze na story, při neshodě zvolit vyšší hodnotu, story s odhadem nad 13 bodů rozpadnout, nepřevádět body na hodiny. Body slouží pro plánování týmu, nikoli pro hodnocení výkonu.
5. Pokročilé techniky
Reference Class Forecasting je technika z behaviorální ekonomie, kterou prosazuje Bent Flyvbjerg. Místo odhadování zdola nahoru se vyhledá databáze podobných minulých projektů a aplikuje se průměrný překročení. Pokud podobné migrace CRM systému historicky překročily odhad o 158 %, je rozumné aplikovat stejnou korekci na nový odhad.
Three-Point Estimation (PERT) kombinuje optimistický (O), nejpravděpodobnější (M) a pesimistický (P) odhad podle vzorce E = (O + 4M + P) / 6 se směrodatnou odchylkou (P − O) / 6. Metoda je vhodná pro rizikové integrace s neznámými dependencies.
T-Shirt Sizing (XS, S, M, L, XL) se hodí pro hrubé portfoliové plánování epiců, kdy detailní Story Points nedávají smysl. Velikosti přibližně mapují na rozpětí 1–3, 5–8, 13–21, 34–55 a 89+ bodů.
6. Hnutí #NoEstimates
Skupina inženýrů kolem Woodyho Zuilla a Vasco Duarta argumentuje, že odhady jsou v některých kontextech zbytečnou režií. Místo odhadování se měří historická průchodnost (throughput) a doba cyklu (cycle time). Forecast je založen na Monte Carlo simulaci nad historickou propustností.
Přístup funguje v interních produktových týmech s vyzrálou DevOps kulturou, kontinuálním nasazováním a stabilním složením týmu. Selhává v zakázkové práci s pevným rozpočtem, kde stakeholdeři potřebují závazek nákladů a termínu. #NoEstimates není absencí plánování, ale jiným způsobem plánování zaměřeným na value flow.
7. Anti-patterns v odhadování
Precision theater: tým debatuje 20 minut o rozdílu mezi 5 a 8 body. Doporučení: time-box diskuze na 5 minut, při nejistotě volit vyšší hodnotu.
Velocity weaponization: management nastaví velocity jako KPI. Tým reaguje inflací bodů – stejná práce dostane vyšší odhad. Velocity ztratí prediktivní hodnotu. Doporučení: velocity je interní plánovací metrika, ne hodnotící nástroj.
Estimate as commitment: odhady se mění v závazky, jejichž nedodržení je trestáno. Tým se brání paddingem. Doporučení: komunikovat odhady jako pravděpodobnosti, používat intervaly spolehlivosti.
Individual estimation: jeden expert odhaduje za celý tým. Doporučení: vždy odhadovat jako tým, využít wisdom of crowds.
8. Metriky pro zlepšování
Klíčové metriky odhadovacího procesu: poměr odhadu k realitě, podíl odhadů s odchylkou do 25 % a do 50 %, podíl katastrofických selhání (odchylka nad 200 %), průměrná doba plánovacího meetingu, počet kol Planning Pokeru na story.
Týmy s vyzrálým procesem dosahují 70 % odhadů v rozmezí ±50 % reality, 35 % v rozmezí ±25 % a méně než 10 % katastrofických selhání. Tato čísla jsou realistický cíl; pokus o vyšší přesnost obvykle znamená padding nebo gaming systému.
9. Doporučený postup
Pro většinu týmů doporučujeme následující kombinaci. Story Points pro produktový vývoj v iteracích, hodinové odhady pouze pro úlohy do 4 hodin práce, T-Shirt Sizing pro portfoliové plánování epiců, Reference Class Forecasting pro odhad celého projektu, Three-Point Estimation pro rizikové integrace, throughput-based forecasting jako kontrolní výpočet.
Plánovací meeting nemá překročit 2 hodiny pro 2týdenní sprint. Jakmile diskuze trvá déle, signalizuje to nedostatečně připravený backlog nebo příliš velké stories.
10. Závěr
Odhadování není věda ani umění, ale inženýrská disciplína založená na zpětné vazbě. Odhady jsou pravděpodobnosti, nikoli sliby. Diskuze nad odhadem je hodnotnější než výsledné číslo. Historická data jsou nejlepší prediktor. Cognitive biases jsou reálné a je třeba s nimi systémově pracovat. Žádná technika nepřinese 90% přesnost; 70 % odhadů v rozmezí ±50 % reality je solidní výsledek vyzrálého týmu.
Reference
- Cohn, M. (2005): Agile Estimating and Planning. Prentice Hall
- Kahneman, D. (2011): Thinking, Fast and Slow. Farrar, Straus and Giroux
- McConnell, S. (2006): Software Estimation: Demystifying the Black Art. Microsoft Press
- Flyvbjerg, B. & Budzier, A. (2011): Why Your IT Project May Be Riskier Than You Think. HBR
- Jørgensen, M. (2004): A review of studies on expert estimation of software development effort. JSS
- Standish Group: CHAOS Report (annual)
