Náš tým o sobě říká, že je velmi maturitní. A možná má pravdu. Má zkušené vývojáře, zná produkt, rozumí technologiím a většinu práce zvládá dodat bez výrazného chaosu. Přesto se opakovaně ukazuje jeden zvláštní problém: agilní odhadování v týmu sice probíhá rychle, ale zhruba polovina odhadů není přesná.
Když se podíváme blíže na to, jak odhadování probíhá, často vidíme jednoduchý vzorec. Jeden vývojář navrhne číslo. Ostatní s ním souhlasí. A jde se dál.
Na první pohled to může působit efektivně. Žádné dlouhé debaty, žádné zdržování, žádné nekonečné kolečko planning pokeru. Jen rychlá dohoda.
Jenže otázka zní: je to ještě skutečný týmový odhad?
Rychlý souhlas není totéž jako týmové porozumění
Pokud jeden člověk navrhne odhad a ostatní ho pouze odsouhlasí, tým ve skutečnosti nemusí odhadovat jako tým. Spíše potvrzuje první návrh.
A právě v tom je problém. Hodnota týmového odhadování není v samotném čísle. Hodnota je v diskusi, která k číslu vede.
Dobré odhadování pomáhá odhalit:
- rozdílné předpoklady členů týmu,
- skrytou technickou složitost,
- nejasná acceptance criteria,
- integrační závislosti,
- testovací náročnost,
- rizika reworku,
- nejistotu, kterou si tým zatím nepřiznal.
Když tato diskuse neproběhne, tým se připraví o hlavní přínos odhadování. Číslo sice vznikne, ale nevznikne společné porozumění.
Nepřesný odhad často není problém sám o sobě. Je to symptom, že tým při refinementu neodhalil důležité nejistoty.
Nejde o to zpochybnit maturitu týmu
V podobné situaci bych nezačínal větou: „Tým není maturitní.“
To by byla zbytečně konfrontační a pravděpodobně i nepřesná interpretace. Tým může být zkušený a přesto může mít špatně nastavený konkrétní mechanismus. V tomto případě mechanismus odhadování.
Lepší formulace může znít takto:
Současný způsob odhadování možná nevyužívá plně zkušenost, kterou v týmu máme.
To je důležitý rozdíl. Neútočíme na schopnosti lidí. Díváme se na proces, který má týmu pomoci dělat lepší rozhodnutí.
Podobně jako u týmových metrik platí, že cílem nemá být kontrola lidí, ale lepší rozhodování. Pokud tým vnímá měření jako hrozbu, vyplatí se nejdříve zavést měření tak, aby pomáhalo, ne škodilo.
Přestaňme řešit přesnost odhadu izolovaně
Když je 50 % odhadů nepřesných, je lákavé říct: „Musíme lépe odhadovat.“
Jenže to samo o sobě týmu příliš nepomůže. Přesnější otázky jsou například:
- U kterých typů práce jsou odhady nejméně přesné?
- Jsou podhodnocené hlavně technické stories, bugy, integrace, závislosti nebo nejasné business požadavky?
- Chybí nám informace už při refinementu?
- Zvětšují se stories až během sprintu?
- Je problém ve velikosti práce, nebo v přerušování a čekání?
- Opakujeme stále stejný typ chyby?
Nepřesný odhad je často jen viditelný projev hlubšího problému. Tým mohl špatně pochopit rozsah práce. Mohl ignorovat závislost. Mohl podcenit testování. Nebo se story během sprintu změnila natolik, že původní odhad přestal dávat smysl.
Proto bychom odhady neměli používat jen jako číslo do sprint planningu, ale jako signál pro učení. Pokud chceme pochopit, proč se odhady opakovaně míjejí s realitou, pomůže dívat se nejen na samotné story points, ale také na flow metriky — například cycle time, lead time, throughput nebo WIP.
Odhady by zároveň neměly být metrikou výkonu týmu. Pokud chceme opravdu porozumět zlepšování dodávky, potřebujeme měřit tok hodnoty, ne aktivitu.
Jak má vypadat skutečné agilní odhadování v týmu
Jednoduché pravidlo může znít:
Každý, kdo se může na realizaci podílet nebo ji bude testovat či reviewovat, musí mít možnost odhadnout nezávisle.
Ve Scrumu jsou to vývojáři, kdo plánují práci potřebnou k vytvoření inkrementu splňujícího Definition of Done. I proto dává smysl, aby odhad nebyl jen potvrzením názoru jednoho člověka, ale skutečnou týmovou diskusí podle principů popsaných ve Scrum Guide.
Prakticky to může vypadat takto:
- Product Owner nebo autor krátce představí story.
- Tým položí otázky.
- Každý člen týmu si zvolí odhad nezávisle.
- Odhady se ukážou najednou.
- Pokud jsou mezi odhady rozdíly, mluví hlavně lidé s nejnižším a nejvyšším odhadem.
- Tým si vyjasní rozdílné předpoklady.
- Teprve potom se dohodne finální odhad.
Cílem není hlasování o čísle. Cílem je zjistit, proč někdo vidí story jako jednoduchou a někdo jiný jako rizikovou.
Právě rozdíl v odhadech je často nejcennější část celého refinementu. Ukazuje, že lidé nepřemýšlí o stejné věci stejným způsobem. A to je informace, kterou chceme mít před sprintem, ne až během něj.
Jednou z jednoduchých technik, jak se vyhnout rychlému souhlasu s prvním číslem, je planning poker. Jeho hodnota není v kartičkách samotných, ale v tom, že členové týmu nejdříve odhadují nezávisle a teprve potom porovnávají rozdíly.
Změňme otázku: ne „kolik bodů?“, ale „co z toho může udělat větší práci?“
V mnoha týmech se odhadování příliš rychle zredukuje na otázku: „Kolik tomu dáme?“
Lepší otázka je:
Co by z této story mohlo udělat větší práci, než si teď myslíme?
Tým by měl před odhadem krátce pojmenovat hlavní nejistoty:
- Je zadání dostatečně jasné?
- Jsou acceptance criteria konkrétní a testovatelná?
- Máme potřebná testovací data?
- Je dostupné prostředí, ve kterém budeme změnu ověřovat?
- Existuje závislost na jiném týmu nebo systému?
- Může změna ovlivnit existující funkcionalitu?
- Víme, jak bude řešení testováno?
Až potom má smysl bavit se o odhadu. Jinak se snadno stane, že tým odhaduje spíše pocit než reálně pochopený rozsah práce.
Pokud tým používá story points, je dobré připomenout, že jejich smyslem není přesně předpovědět hodiny práce. Měly by pomáhat relativně porovnat velikost, složitost a nejistotu jednotlivých položek.
Používejme odhad jako trigger pro rozpad práce
Vysoký odhad nebo velký rozdíl mezi odhady by neměl skončit jen tím, že tým zapíše větší číslo.
Taková situace by měla spustit další otázky:
- Není story příliš velká?
- Neměli bychom ji rozdělit?
- Nepotřebujeme nejdříve spike?
- Nechybí nám důležitá informace?
- Nemáme zde závislost, kterou je potřeba vyřešit před sprintem?
- Není část práce technická příprava, kterou bychom měli oddělit?
Scrum.org popisuje sizing Product Backlog Items také jako práci s velikostí položek tak, aby byly dostatečně malé a zvládnutelné v rámci jednoho sprintu. Proto je užitečné chápat sizing Product Backlog Items nejen jako „určení čísla“, ale jako rozhodnutí, zda je položka pro tým skutečně připravená a dostatečně malá.
Pokud se tým nedokáže shodnout bez delší diskuse, není to selhání. Je to signál. Story možná ještě není připravená do sprintu.
Maturitní tým se nepozná podle toho, že všechno rychle odhadne. Pozná se podle toho, že dokáže včas říct: „Tomuhle ještě dostatečně nerozumíme.“
Dělejme krátkou kalibraci po sprintu
Na konci sprintu není potřeba analyzovat každou story. Stačí se podívat na několik vybraných případů:
- story byla odhadnutá nízko, ale zabrala výrazně více práce,
- story měla vysoký odhad, ale byla dokončena překvapivě rychle,
- story spillnula do dalšího sprintu,
- story vytvořila další neplánovanou práci,
- story způsobila rework nebo bugy.
U každého případu stačí jednoduchá otázka:
Co jsme při odhadu nevěděli, přehlédli nebo ignorovali?
Cílem není zpětně přepočítávat body. Cílem je vytvořit lepší checklist pro další refinement.
Pokud tým už sleduje cycle time, throughput nebo spillover, může tuto kalibraci propojit s reálnými daty. Ne proto, aby se hledal viník, ale aby se tým lépe učil z reality. Právě k tomu jsou užitečné flow metriky — ne jako náhrada diskuse, ale jako vstup do ní.
Praktický experiment na 2–3 sprinty
Pokud bych měl týmu navrhnout jednoduchý experiment, zněl by takto:
Nejdříve pojmenujme předpoklady a rizika. Teprve potom dávejme číslo.
U každé významnější story si tým před odhadem zapíše:
- co musí platit, aby byl odhad realistický,
- co je hlavní nejistota,
- co může způsobit navýšení práce,
- podle čeho poznáme, že je story příliš velká.
Jednoduchá tabulka může vypadat například takto:
| Story | Odhad | Klíčové předpoklady | Hlavní riziko |
|---|---|---|---|
| Úprava login flow | 5 | API contract je stabilní, QA prostředí je dostupné, není potřeba změna v napojeném systému | Závislost na identity provideru |
| Nová brand-specific validace | 3 | Pravidla jsou kompletně specifikovaná, testovací data jsou dostupná | Chybějící edge cases |
| Performance improvement mapperu | 8 | Umíme změřit baseline, máme přístup k relevantním logům, změna neovlivní autorizaci | Skrytý dopad do více částí aplikace |
Tím se z odhadu stane transparentní týmová dohoda. Ne jen číslo v ticketu.
Jak bych to otevřel s týmem
Citlivost je v této situaci důležitá. Pokud tým sám sebe vnímá jako vyspělý, není dobré začít tím, že mu tuto vyspělost budeme brát.
Použil bych například tuto formulaci:
Nechci zpochybňovat maturitu týmu. Naopak si myslím, že máme v týmu hodně zkušeností. Mám ale pocit, že náš současný způsob odhadování tyto zkušenosti plně nevyužívá. Pokud jeden člověk navrhne číslo a ostatní ho potvrdí, můžeme minout důležité předpoklady, rizika nebo rozdílné pohledy. Navrhuji proto, abychom na několik refinementů zkusili nezávislé odhadování a věnovali se hlavně rozdílům v odhadech. Cílem nejsou dokonalé odhady, ale méně překvapení během sprintu.
Taková formulace nesoudí lidi. Otevírá prostor pro zlepšení konkrétní praktiky.
Co si z toho odnést
Maturitní tým se nepozná podle toho, že má vždy přesné odhady.
Pozná se spíše podle toho, že:
- otevřeně pracuje s nejistotou,
- umí rozpoznat špatně připravenou story,
- kalibruje se podle reality,
- neskrývá rizika za rychlý konsensus,
- používá odhady k lepším rozhodnutím, ne k obraně závazků.
Pokud polovina odhadů nevychází, není potřeba hledat viníka. Je potřeba změnit konverzaci.
Dobré agilní odhadování proto není o přesnosti za každou cenu. Je hlavně o tom, zda tým dokáže včas otevřít správnou diskusi o rozsahu, riziku a nejistotě.
Odhadování nemá být jen dohoda na čísle. Má to být krátká, ale kvalitní týmová diskuse o tom, čemu rozumíme, čemu ještě nerozumíme a kde nás může práce překvapit.
A právě tam začíná skutečná týmová maturita.
Jak to řešíte vy?
Máte v týmu odhadování jako skutečnou diskusi, nebo spíše jako rychlé potvrzení prvního návrhu? A co vám nejvíce pomáhá odhalovat nejistoty ještě před začátkem sprintu?
Pokud vás zajímá, jak odhady propojit s reálnou predikovatelností dodávky, podívejte se také na další texty z oblasti flow, metrik a týmového zlepšování.