Je poslední den sprintu. Tým má za sebou dva týdny intenzivní práce, ale na tabuli stále zůstávají tři nedokončené stories. Jedna čeká na testování, druhá na rozhodnutí stakeholdera a u třetí se během implementace ukázalo, že je podstatně větší, než se původně zdálo.
Při Sprint Review se hotová část odprezentuje. Zbytek se přesune do dalšího sprintu. Při následujícím plánování už nový sprint nezačíná s čistým stolem: část kapacity je předem obsazená starou prací.
O dva týdny později se situace opakuje.
Leadership začne mluvit o nízké předvídatelnosti, Product Owner o nepřesných odhadech a tým o tom, že se mu během sprintu neustále mění priority. Někdo navrhne zavést metriku spillover rate a stanovit pravidlo, že nesmí překročit deset procent.
Samotné číslo ale problém nevyřeší. Může ho dokonce zakrýt.
Spillover nevzniká poslední den sprintu. Poslední den sprintu se pouze ukáže.
Co je spillover rate
Spillover rate vyjadřuje, jaká část práce naplánované do sprintu nebyla během sprintu dokončena a přechází do dalšího období.
Nejde o oficiální Scrum metriku ani o ukazatel s jednou univerzálně platnou definicí. Každý tým nebo organizace si proto musí nejprve ujasnit, co přesně pod spilloverem počítá.
Jednoduchý výpočet může vypadat takto:
Spillover rate = nedokončená práce z původního plánu sprintu / celková práce v původním plánu sprintu × 100
Pokud tým na začátku sprintu naplánoval deset položek a tři z nich nedokončil, spillover rate podle počtu položek činí 30 %.
Výpočet je jednoduchý. Interpretace už tak jednoduchá není.
Počet položek, nebo Story Points?
Spillover lze počítat podle počtu položek, Story Points nebo jiné jednotky velikosti.
Počet položek je srozumitelný a relativně snadno ověřitelný. Jeho slabinou je, že malá úprava textu má stejnou váhu jako rozsáhlá integrace několika systémů.
Story Points rozdíly ve velikosti částečně zachytí, ale ani ony nejsou objektivní jednotkou. Jsou specifické pro konkrétní tým a mohou být zkreslené způsobem odhadování.
V praxi doporučuji začít počtem položek. Pokud jsou jejich velikosti výrazně rozdílné, lze přidat druhý pohled podle Story Points. Ještě užitečnější bývá doplnit spillover o cycle time, throughput a stáří rozpracované práce.
Původní scope není totéž co scope na konci sprintu
Velmi častou chybou je porovnat konečný stav sprintu s tím, co se v něm nachází poslední den. Tím se ale smíchá původní plán s prací, která byla během sprintu přidána nebo odebrána.
Pro smysluplné vyhodnocení je vhodné oddělit:
- práci naplánovanou na začátku sprintu,
- práci přidanou během sprintu,
- práci ze sprintu odebranou,
- dokončenou práci,
- práci přenesenou do dalšího sprintu.
Bez tohoto rozlišení může tým vypadat jako nespolehlivý, přestože původní plán byl realistický a hlavní problém spočíval v množství nových priorit přidaných během sprintu. Této situaci se podrobněji věnuje článek Sprint overcommitment: proč tým nestíhá plán, i když pracuje naplno.
Co nám spillover rate skutečně říká
Spillover rate není diagnóza. Je to signál, že mezi plánovaným a skutečným způsobem dodávky existuje rozdíl.
Tento rozdíl může mít několik zcela odlišných příčin.
1. Plán neodpovídá skutečné dodávkové schopnosti
Tým může pravidelně plánovat více práce, než je podle historických dat schopen dokončit. Často se přitom neopírá o skutečný throughput, ale o nominální kapacitu lidí, průměrnou velocity nebo představu, co by se „mělo stihnout“.
Plánování je vždy forecast, tedy kvalifikovaný odhad budoucnosti. Není to jistota. Scrum Guide ostatně popisuje Sprint Backlog jako plán vytvářený vývojáři a průběžně aktualizovaný podle toho, co se během sprintu učí. Důležitým stabilizujícím prvkem je Sprint Goal, nikoliv neměnný seznam ticketů.
Pokud se forecast dlouhodobě rozchází s realitou, je na místě změnit způsob plánování. Ne nutně zvýšit tlak na tým.
2. Položky jsou příliš velké nebo nepřipravené
Čím větší položka je, tím více nejistoty, závislostí a skrytých předání obvykle obsahuje. Story může mít popis, acceptance criteria, odhad i stav Ready, a přesto nemusí být reálně dokončitelná.
Typický příklad:
- tým zahájí změnu zákaznického portálu,
- během vývoje zjistí, že potřebné API ještě neexistuje,
- tester nemá vhodná testovací data,
- část řešení musí schválit bezpečnostní oddělení,
- spolupracující tým nemá související práci ve svých prioritách.
Problém nevznikl poslední den sprintu. Vznikl už ve chvíli, kdy tým převzal práci, kterou mohl začít, ale nemohl bezpečně dokončit.
Praktický test připravenosti popisujeme v článku Pullability: jednoduchý test, jestli si tým může práci opravdu vzít.
3. Tým zahajuje více práce, než dokáže dokončit
Tým může naplánovat přiměřené množství práce, ale přesto vytvořit vysoký spillover kvůli způsobu, jakým práci uvnitř sprintu řídí.
Vývojář dokončí programování a story předá do testování. Tester má ale frontu několika dalších položek. Vývojář proto zahájí novou story, aby nezůstal bez práce. Postupně vzniká více rozpracovaných položek, ale nic se nedokončuje rychleji.
Lokálně jsou lidé vytížení. Z pohledu celého systému se však prodlužuje cycle time a zvyšuje riziko, že práce přeteče.
V takové situaci obvykle více pomůže omezení WIP, dřívější testování a pravidlo „stop starting, start finishing“ než další zpřesňování odhadů. Čtyři základní flow metriky — WIP, cycle time, work item age a throughput — shrnuje také materiál Scrum.org 4 Key Flow Metrics and How to Use Them in Scrum’s Events.
4. Priority nejsou během sprintu stabilní
Do sprintu může vstoupit produkční incident, regulatorní změna, požadavek důležitého klienta nebo nová priorita vedení. To samo o sobě nemusí být špatně. Některé situace skutečně vyžadují rychlou reakci.
Problém vzniká, pokud organizace neumí rozhodnout, co se má po přidání nové práce přestat dělat.
Když se urgentní práce pouze přidává, původní plán přestává být realistický. Následný spillover pak nevypovídá primárně o schopnosti týmu odhadovat. Vypovídá o kvalitě prioritizace a pravidel pro změny scope.
5. Překážka leží mimo tým
Některé týmy mají backlog připravený, položky rozumně malé a vnitřní tok práce relativně zdravý. Přesto jim práce přetéká kvůli čekání na jiné týmy, schválení, prostředí, architekty nebo specializované role.
V takovém případě nepomůže další týmová retrospektiva zaměřená na „lepší commitment“. Potřebujete změnit systém koordinace a rozhodování.
Místo otázky „Proč jste to nedokončili?“ se ptejte: „Kde práce čekala a kdo může tuto překážku odstranit?“
Co spillover rate neříká
Číslo je užitečné pouze tehdy, když rozumíme jeho hranicím.
Neříká, zda lidé pracovali dostatečně intenzivně
Tým může pracovat naplno a přesto nedokončit plán kvůli blokacím, neplánované práci, závislostem nebo pozdnímu testování. Spillover proto není vhodný pro hodnocení individuálního výkonu ani pracovní morálky.
Neříká, zda sprint přinesl hodnotu
Tým může dokončit všechny naplánované tickety a přesto nedodat smysluplný zákaznický výsledek. Naopak může splnit hlavní Sprint Goal a ponechat nedokončenou jednu doplňkovou položku.
Proto je vhodné hodnotit spillover společně s úspěšností Sprint Goal a skutečně dosaženým výsledkem.
Neříká automaticky, že má tým plánovat méně
Tým může začít plánovat velmi konzervativně, všechny položky dokončit a během sprintu si průběžně přidávat další práci. Formální spillover klesne na nulu, ale předvídatelnost ani tok se nemusí zlepšit.
Optimalizovali jsme číslo, nikoliv systém.
Neumožňuje férově porovnávat týmy
Týmy mají rozdílný charakter práce, míru supportu, závislosti, workflow, velikost položek i Definition of Done. Porovnání spillover rate mezi dvěma týmy proto zpravidla vytváří více otázek než odpovědí.
Obecnější principy bezpečné práce s metrikami rozebírá článek Proč se agilní týmy bojí metrik.
Stejný spillover, tři různé problémy
Představme si tři týmy. Každý má spillover rate 25 %. Přesto každý potřebuje jiný zásah.
Tým A: příliš mnoho paralelní práce
Scope sprintu se téměř nemění. Tým ale zahájí většinu stories během prvních několika dnů a dokončuje je až na konci sprintu. Testování se pravidelně stává úzkým místem.
Pravděpodobný zásah: snížit WIP, dokončovat položky postupně a plánovat podle historického throughputu.
Tým B: neplánovaná práce
Během sprintu přibylo množství urgentních požadavků odpovídající třetině původního plánu. Původní stories byly odsunuty, protože incidenty měly vyšší prioritu.
Pravděpodobný zásah: oddělit plánovatelnou a neplánovatelnou práci, vytvořit kapacitní rezervu a nastavit jasná pravidla pro urgentní požadavky.
Tým C: externí závislosti
Tým má nízký WIP a vlastní část práce zvládá rychle. Několik stories však dlouho čeká na schválení a integraci s jiným týmem.
Pravděpodobný zásah: řešit cross-team koordinaci, pořadí priorit a dostupnost sdílených kompetencí.
Číslo je ve všech případech stejné. Příčina i potřebná intervence jsou zcela jiné.
Jak spillover správně vyhodnocovat
Sledujte trend, ne jeden sprint
Jeden sprint může ovlivnit nemoc, produkční incident, změna priority nebo technické překvapení. Vyhodnocujte proto alespoň šest až deset sprintů a sledujte, zda se výsledek stabilizuje, zlepšuje nebo zhoršuje.
Rozdělte spillover podle příčiny
U každé přenesené položky zaznamenejte jednu hlavní příčinu. Pro začátek stačí například:
- příliš velká položka,
- změna scope,
- neplánovaná práce,
- externí závislost,
- technický problém,
- čekání na testování nebo review,
- nedostatečná připravenost.
Cílem není vytvořit dokonalou taxonomii. Cílem je objevit opakující se vzorec.
Sledujte stáří přenášených položek
Story přenesená jednou není totéž jako story putující třetím sprintem. U opakovaně přenášené práce sledujte work item age, dobu blokace a počet sprintů od zahájení.
Stárnoucí položka často představuje významnější riziko než několik drobných stories přenesených jednorázově.
Kombinujte spillover s dalšími metrikami
Spillover rate doporučuji vyhodnocovat společně minimálně s těmito ukazateli:
- scope change rate – kolik práce během sprintu přibylo nebo ubylo,
- throughput – kolik položek tým skutečně dokončuje,
- cycle time – jak dlouho dokončení položky trvá,
- work item age – jak dlouho jsou aktuální položky rozpracované,
- Sprint Goal Success Rate – zda tým dosáhl hlavního výsledku sprintu.
Výběr vhodné kombinace metrik podle konkrétní situace týmu popisuje článek Jak vybrat týmové KPIs: 5 situací a 3 metriky pro každou z nich.
Typické chyby
1. Stanovení univerzální cílové hodnoty
Požadavek „spillover musí být pod 10 %“ může působit konkrétně, ale bez znalosti výchozího stavu a příčin vede často jen ke kosmetickým úpravám.
Tým začne plánovat méně, administrativně dělit stories nebo před koncem sprintu měnit jejich stav. Číslo se zlepší, skutečný problém zůstane.
2. Zaměňování forecastu za pevný závazek ke scope
Sprintový plán není smlouva na přesný seznam ticketů bez ohledu na nové informace. Důležitá je transparentnost změn, ochrana Sprint Goal a vědomé rozhodování o rozsahu.
Oficiální definice Sprint Backlogu, Sprint Goal a Incrementu nabízí Scrum Guide.
3. Automatické přesouvání práce do dalšího sprintu
Nedokončená položka by neměla být automaticky považována za nejvyšší prioritu dalšího sprintu. Stále má patřit do Product Backlogu a projít novým rozhodnutím o prioritě.
Mezitím se mohl změnit kontext, hodnota nebo potřeba dané změny.
4. Zpřesňování odhadů místo zlepšování toku
Když práce čeká na testování nebo schválení, detailnější odhad nepomůže. Pokud jsou položky příliš velké, je potřeba lepší slicing. Pokud tým zahajuje příliš mnoho práce, je potřeba omezit WIP.
5. Porovnávání týmů
Žebříček týmů podle spillover rate vytváří motivaci upravovat plán a data, nikoliv transparentně ukazovat překážky.
6. Ignorování typu práce
Produktový tým s relativně stabilním cílem má jiné podmínky než supportní tým, který denně reaguje na nové požadavky. Pokud práce přichází průběžně a nelze ji na začátku sprintu rozumně stabilizovat, může být vhodnější řídit ji jako flow.
Více o této volbě najdete v článku Potřebujete opravdu sprinty? Možná je pro vás vhodnější flow tým. Praktické principy omezení WIP a řízení toku shrnuje také The Kanban Guide.
Jak začít v praxi
Není potřeba zavádět nový dashboard ani rozsáhlý reporting. Začněte jednoduchým experimentem nad posledními sprinty.
1. Dohodněte definici
Společně si vyjasněte:
- co považujete za původní plán sprintu,
- co znamená dokončená položka,
- jak zachytíte přidaný a odebraný scope,
- zda budete počítat položky, Story Points, nebo oba pohledy.
2. Získejte výchozí stav
Vyhodnoťte posledních šest až deset sprintů. Nesnažte se zatím nastavovat cílovou hodnotu. Nejprve potřebujete porozumět tomu, co se skutečně děje.
3. U každé přenesené položky určete hlavní příčinu
Stačí jedna dominantní příčina. Dlouhý seznam důvodů obvykle zhorší přehlednost a zkomplikuje hledání vzorců.
4. Hledejte systémový vzorec
Ptejte se:
- Který typ práce přetéká nejčastěji?
- V jakém stavu položky obvykle čekají?
- Kolik práce bylo přidáno během sprintu?
- Jsou položky příliš velké?
- Opakují se stejné závislosti?
- Je příčina pod kontrolou týmu, Product Ownera, nebo leadershipu?
5. Vyberte jeden experiment
Podle zjištěné příčiny může jít například o:
- snížení WIP,
- menší slicing stories,
- plánování podle historického throughputu,
- kapacitní rezervu na neplánovanou práci,
- průběžné testování,
- pravidla pro vstup urgentní práce,
- aktivní sledování work item age,
- vyřešení konkrétní cross-team závislosti.
Nesnažte se v jednom sprintu změnit všechno. Jeden dobře zvolený experiment přinese více než rozsáhlý seznam obecných opatření.
6. Vyhodnoťte dopad po několika sprintech
Nesledujte pouze spillover. Ověřte také, zda klesá rozpracovanost, zkracuje se cycle time, stabilizuje se throughput a zvyšuje se pravděpodobnost dosažení Sprint Goal.
Kdy už nestačí týmová retrospektiva
Někdy analýza spilloveru ukáže, že hlavní problém neleží uvnitř týmu. Priority se mění z několika míst, závislosti se řeší až po zahájení práce, specializované role jsou trvalým úzkým místem nebo plánování tlačí na vysoké vytížení místo dokončování výsledků.
V takové situaci je potřeba podívat se na celý pracovní systém: způsob prioritizace, pravidla toku, WIP, rozhodovací pravomoci i spolupráci mezi týmy.
Pokud je hlavní problém ve stabilitě plánování, změnách scope a důvěryhodnosti závazků, může být vhodným cíleným zásahem Predictability Reset. Pokud práci brzdí vysoká rozpracovanost, dlouhé čekání a nejasná pravidla toku, dává větší smysl zaměřit se na flow.
Když příčina zatím není jasná, je obvykle užitečnější nejprve získat objektivní obraz systému než okamžitě zavádět další proces nebo metriku. Přehled cílených konzultačních formátů najdete mezi produkty Agile Brothers.
Praktické mikrokurzy, checklisty a toolkity k toku práce, předvídatelnosti a týmovým metrikám postupně doplňujeme také v Agile Brothers Academy.
Závěrečné shrnutí
Spillover rate ukazuje rozdíl mezi prací naplánovanou do sprintu a prací, kterou tým skutečně dokončil. Neříká ale automaticky, proč tento rozdíl vznikl.
Za pravidelným přetékáním může být:
- nerealistický forecast,
- příliš velká nebo nepřipravená práce,
- vysoký WIP,
- pozdní testování,
- neplánovaná práce,
- změny priorit,
- externí závislosti a systémová úzká místa.
Proto nemá smysl požadovat nízký spillover bez znalosti kontextu. Tým by pravděpodobně začal optimalizovat číslo místo systému.
Užitečnější je sledovat trend, rozlišovat příčiny a kombinovat spillover se scope change rate, throughputem, cycle time, work item age a dosažením Sprint Goal.
Metrika má pomoci najít překážku, ne člověka, kterého za ni potrestáme.
Pokud spillover vede k lepším otázkám o velikosti práce, toku, prioritách a závislostech, plní svůj účel. Pokud slouží pouze jako další číslo v manažerském dashboardu, pravděpodobně skutečnou předvídatelnost nezlepší.