Rozložit odhad času na analytickou fázi a samotnou implementaci je v agilním týmu klíčové pro udržitelné tempo a předvídatelnost. Základním pravidlem je, že analytiku nikdy neodhadujete jako procentuální přirážku k implementaci, ale jako samostatnou jednotku práce s vlastním rozsahem. Začněte tím, že si zadání rozdělíte na menší celky, ideálně na úroveň uživatelských příběhů, a u každého si položte tři otázky: Jak dobře známe doménu? Kde jsou nejistoty v chování systému? A kdo bude výstup analýzy konzumovat? Pokud odpovídáte nejasně, počítejte s tím, že analytická fáze zabere klidně polovinu celkového odhadu času. V praxi se vyplatí stanovit si poměr podle složitosti: pro dobře známou oblast může být analýza třetinou času implementace, u nové funkcionality s mnoha závislostmi se klidně může vyrovnat. Tento poměr si ale vždy verbalizujte v týmu, aby nevznikl dojem, že odhad času je jen číslo pro implementaci, a analýza se pak řešila na koleně.
Pro samotné plánování doporučuji použít techniku dvou samostatných odhadů, které si zapíšete do dvou sloupců. Nejprve odhadněte implementaci v ideálním světě, tedy čistý kód, testy a integraci bez překvapení. K tomuto číslu si pak připočítejte rezervu na objevené závislosti, ale tuto rezervu nesměšujte s analytickým časem. Následně odhadněte analýzu jako čas potřebný k tomu, abyste dokázali implementaci spustit bez přerušení. To znamená: příprava dat, definice akceptačních kritérií, návrh rozhraní a identifikace rizik. Velmi praktické je naplánovat analytickou fázi do prvních dvou dnů sprintu a implementaci až po jejím dokončení, ale s tím, že výsledek analýzy je revidovaný odhad. Pokud analytik objeví, že je potřeba změnit datový model, musíte mít odvahu vrátit se k product ownerovi a upravit původní odhad času, jinak pouze přesunete problém do zpoždění na konci sprintu. Nezapomínejte, že každá analytická činnost, která není zachycena v odhadu, se nutně projeví jako přerušení implementace, což je nejdražší varianta.
Největší chybou bývá snaha o přesnost na začátku, kdy ještě nemáte dostatek informací. Místo toho si osvojte princip postupného upřesňování: na úrovni epiku odhadujte analýzu a implementaci dohromady jako jeden časový rámec, ale při rozpadu na úkoly v rámci sprintu je důsledně oddělujte. Konkrétně vám doporučuji, aby každý uživatelský příběh měl vždy dva samostatné tasky, jeden s předponou ANALÝZA a druhý IMPLEMENTACE, a při daily standupu sledujte, jestli se nezpožďuje ten analytický. Pokud se tak stane, okamžitě to komunikujte, protože zpoždění analýzy se nepromítne do implementace lineárně, ale exponenciálně. Také si stanovte pravidlo, že analytik nesmí během implementace dodávat nové požadavky přímo na vývojáře, ale výstupy musí jít přes zde , aby tým měl šanci reagovat. Tím dosáhnete toho, že odhad času bude sloužit jako nástroj pro řízení očekávání, nikoli jako právní dokument, a vaše sprinty budou plynulejší. Vždy po skončení iterace porovnejte odhadnutý analytický čas se skutečným a použijete to jako vstup pro příští plánování, čímž se vaše schopnost odhadovat s každým sprintem zlepšuje.