Sprint overcommitment často nevzniká jen proto, že tým při Sprint Planningu špatně odhadne kapacitu. Velmi často vzniká až během sprintu. Do sprintu se přidávají nové důležité stories, urgentní požadavky, bugy nebo technické problémy – ale původní plán zůstává formálně beze změny.
Výsledkem je situace, kdy tým pracuje naplno, ale na konci sprintu stejně vypadá jako nespolehlivý. Nedodá původně plánované položky, roste spillover a při retrospektivě se znovu řeší, proč se „nestihlo všechno“. Jenže otázka často nemá znít: Proč tým nestihl plán? Správnější otázka je: Byl to na konci sprintu ještě stejný plán?
Sprint overcommitment není vždy problém rychlosti týmu
Když tým nedodá vše, co bylo naplánováno, první podezření často míří na odhady, produktivitu nebo disciplínu. To může být oprávněné. Ale pokud během sprintu přibývá další práce, původní plán přestává být férovým měřítkem.
Představme si tým, který si na dva sprinty naplánuje určitý objem práce. Během těchto sprintů ale dodá navíc 8 neplánovaných stories a zároveň řeší bugy. Na papíře může sprint vypadat jako nedokončený. Ve skutečnosti tým možná dodal hodně práce – jen jinou, než byla součástí původního sprintového závazku.
Právě tady vzniká sprint overcommitment: nikoliv jednorázovým rozhodnutím na Sprint Planningu, ale postupným přidáváním práce bez jasného rozhodnutí, co naopak ze sprintu odchází.
Typické příznaky přeplánovaného sprintu
- Do sprintu se během jeho průběhu přidávají nové stories.
- Bugy se řeší paralelně, ale nejsou vidět v kapacitě týmu.
- Původně plánované položky se odsouvají bez explicitního rozhodnutí.
- Na konci sprintu roste spillover.
- Daily Scrum se mění ve status meeting, ale nevede k reálnému řízení rizik.
- Product Owner, stakeholder nebo management očekává původní plán i nově přidanou práci.
- Tým má pocit, že „dodal hodně“, ale metriky ukazují nízkou predictability.
Taková situace není jen problém týmu. Je to systémový problém řízení práce. Pokud se má agilita projevit v lepší produktivitě a schopnosti dodávat hodnotu, nestačí přidávat ceremonie. Je potřeba zviditelnit skutečný tok práce, omezit paralelní rozpracovanost a lépe řídit změny priorit. Právě těmto tématům se věnujeme i v rámci naší práce s klienty v Agile Brothers.
Problém: nové stories vstupují do sprintu bez výměny za jinou práci
Nejčastější příčina sprint overcommitmentu je jednoduchá: nová práce vstoupí do sprintu, ale nic jiného ze sprintu neodejde.
To se obvykle děje nenápadně. Objeví se nový důležitý požadavek. Stakeholder jej označí jako urgentní. Product Owner ho přidá do sprintu, protože opravdu dává smysl. Tým ho vezme, protože chce pomoci. Jenže původní sprint backlog zůstane prakticky stejný.
V tu chvíli vzniká tichá dohoda, kterou nikdo nevyslovil: tým má dodat původní plán i novou práci. A právě tato tichá dohoda je jádrem problému.
Nová důležitá práce není problém. Problém je nová práce bez vědomého rozhodnutí, co za ni ze sprintu vyměníme.
Sprint Goal jako ochrana před chaosem
Scrum Guide popisuje Sprint Goal jako důležitý prvek, který dává sprintu fokus. Daily Scrum má podle Scrum Guide sloužit k inspekci postupu vůči Sprint Goal a k adaptaci Sprint Backlogu podle aktuální situace. Více k tomu najdete přímo ve Scrum Guide.
To je pro řízení sprint overcommitmentu zásadní. Tým by se neměl ptát jen: Stihneme všechny tickety? Měl by se ptát hlavně:
- Je Sprint Goal stále realistický?
- Podporuje nově přidaná práce Sprint Goal?
- Ohrožuje nová práce původní závazek sprintu?
- Co musíme ze sprintu odebrat, aby plán zůstal realistický?
Scrum.org k tomu prakticky vysvětluje, že pokud se práce během sprintu ukáže jako jiná, než tým očekával, Developers spolupracují s Product Ownerem na vyjednání rozsahu Sprint Backlogu, aniž by změnili Sprint Goal. Tento princip je dobře popsaný v článku The Sprint Goal is a commitment for the Sprint Backlog.
Zaveďte jednoduché pravidlo: one in, one out
Nejpraktičtější týmová dohoda pro řízení změn ve sprintu zní:
Každá nová story přidaná do aktivního sprintu musí nahradit jinou položku podobné velikosti nebo nižší priority.
V angličtině se toto pravidlo často formuluje jako:
Any new story added to an active sprint must replace another item of similar size or lower priority.
Toto pravidlo neznamená, že se sprint nesmí měnit. Naopak. Umožňuje změnu, ale vyžaduje vědomé rozhodnutí. Pokud je nová story opravdu důležitější než původně plánovaná práce, pak má do sprintu vstoupit. Ale zároveň by mělo být jasné, co tím pádem ze sprintu odchází.
Ne každá důležitá věc je urgentní pro aktuální sprint
Dalším častým zdrojem sprint overcommitmentu je záměna důležitosti a urgentnosti. Něco může být důležité pro produkt, stakeholdera nebo zákazníka. To ale ještě neznamená, že to musí vstoupit do aktuálního sprintu.
Před přidáním nové story do sprintu pomůže jednoduchý filtr:
| Otázka | Doporučená reakce |
|---|---|
| Blokuje tato práce aktuální Sprint Goal? | Může vstoupit do sprintu. |
| Je nutná kvůli releasu nebo produkčnímu problému? | Může vstoupit do sprintu, ale vyžaduje trade-off. |
| Blokuje jiný tým nebo klíčového stakeholdera? | Zvážit vstup do sprintu podle dopadu. |
| Je to jen nově objevená priorita? | Spíše zařadit do dalšího sprintu. |
| Má nejasný rozsah nebo chybí akceptační kritéria? | Nejdříve refinement nebo spike. |
Zejména poslední bod bývá kritický. Pokud do sprintu vstupují nejasné stories, tým nepřijímá jen novou práci, ale i nové riziko. Kvalita backlogu, velikost User Stories a jasná akceptační kritéria proto přímo ovlivňují stabilitu sprintu. Prakticky se tomuto tématu věnuje náš workshop Agilní backlog s Epicy, Features a User Stories.
Bugy nesmí být neviditelná práce
Bugy jsou samostatná kapitola. V mnoha týmech se bugy během sprintu prostě „nějak vyřeší“. Jenže kapacita, kterou tým spotřebuje na bug fixing, pak chybí jinde.
Proto je důležité rozlišit různé typy bugů:
| Typ bugu | Jak s ním pracovat |
|---|---|
| Bug blokující story ve sprintu | Řešit okamžitě jako součást dodání dané story. |
| Kritický produkční bug | Řešit okamžitě, i za cenu změny sprint scope. |
| High priority bug | Product Owner rozhodne, zda nahradí jinou práci. |
| Medium / low priority bug | Zařadit do backlogu a naplánovat podle priority. |
| Bug nalezený při vývoji story | Typicky součást dokončení story, ne extra scope. |
Klíčové je, aby bugy nebyly mimo systém. Pokud tým během sprintu řeší významné bugy, musí být vidět na boardu, v kapacitě a v metrikách. Jinak bude opakovaně vznikat dojem, že tým „nedodal plán“, i když část kapacity spotřebovala nezbytná kvalitativní práce.
Vytvořte Sprint Scope Change Log
Jedním z nejjednodušších a nejúčinnějších nástrojů je Sprint Scope Change Log. Nemusí jít o složitou administrativu. Stačí jednoduchá tabulka, která zachytí, jak se sprint během svého průběhu změnil.
| Datum | Přidáno do sprintu | Důvod | Velikost | Co bylo odebráno | Rozhodl |
|---|---|---|---|---|---|
| 3. den sprintu | Story X | Blokuje release | 5 | Story Y | PO |
| 5. den sprintu | Bug A | Blokuje Story B | 2 | Nic – součást Story B | Tým |
| 7. den sprintu | Story Z | Nová stakeholder priorita | 3 | Story C | PO |
Tento log pomáhá změnit debatu v retrospektivě. Místo obecného pocitu „nestihli jsme sprint“ můžete říct:
- Původně jsme plánovali tento rozsah.
- Během sprintu přibylo tolik nové práce.
- Tolik práce jsme odebrali.
- Tolik práce zůstalo navíc bez výměny.
- Tady vznikl skutečný sprint overcommitment.
Měřte scope churn, nejen spillover
Spillover sám o sobě neříká celý příběh. Pokud tým nedodá 4 plánované stories, ale zároveň dodá 4 neplánované stories a 3 bugy, nejde jen o problém výkonnosti. Jde o problém změny rozsahu sprintu.
Doporučené metriky:
| Metrika | Co ukazuje |
|---|---|
| Planned Delivery Rate | Kolik původně plánované práce tým skutečně dodal. |
| Unplanned Stories Delivered | Kolik nových stories tým absorboval během sprintu. |
| Bug Effort Delivered | Kolik kapacity spotřebovaly bugy. |
| Scope Added | Kolik práce bylo do sprintu přidáno. |
| Scope Removed | Kolik práce bylo ze sprintu odebráno. |
| Scope Churn | Jak moc se sprint změnil oproti původnímu plánu. |
Tyto metriky pomáhají týmu i stakeholderům pochopit realitu. Sprint nebyl jen „nedodaný“. Sprint se v průběhu změnil. A pokud se mění často, je potřeba to řídit vědomě, ne skrytě.
Podobný princip platí i na vyšší úrovni agilního řízení. Pokud chcete zlepšovat týmovou nebo programovou výkonnost, potřebujete měřit věci, které skutečně ovlivňují tok hodnoty. Další praktické články k těmto tématům najdete také na blogu Agile Brothers Academy.
Daily Scrum jako nástroj řízení rizika, ne status meeting
Pokud tým trpí sprint overcommitmentem, Daily Scrum by se neměl soustředit jen na otázku, kdo co dělal včera. Měl by pomáhat řídit riziko nedodání.
Užitečné otázky pro Daily Scrum:
- Co dnes můžeme dokončit?
- Které stories jsou v riziku?
- Co je blokované?
- Potřebujeme na něčem pracovat společně?
- Přibyla nová práce, která ohrožuje Sprint Goal?
- Musíme něco ze sprintu odebrat?
Scrum.org ve svých materiálech ke Sprint Backlogu připomíná, že Sprint Backlog není jen seznam vybraných položek, ale také plán pro dosažení Sprint Goal. Více k tomu najdete v přehledu What is a Sprint Backlog?.
Dohoda pro tým: jak řídit změny ve sprintu
Pro týmy, které opakovaně trpí přeplánovanými sprinty, se hodí jednoduchá pracovní dohoda:
Sprint Scope Change Policy
- Sprint backlog je po Sprint Planningu stabilní výchozí plán.
- Nová práce může vstoupit do sprintu jen tehdy, pokud blokuje Sprint Goal, release, produkční provoz nebo je Product Ownerem explicitně označena za důležitější než původně plánovaná práce.
- Každá nová story přidaná do sprintu vyžaduje trade-off: jiná story je odebrána, nebo je explicitně upraven sprintový závazek.
- Bugy blokující plánované stories se řeší jako součást dodání těchto stories.
- Neblokující bugy se triagují a plánují podle priority.
- Všechny významné změny se zapisují do Sprint Scope Change Logu.
- Scope churn se pravidelně vyhodnocuje v retrospektivě.
Jak začít hned v příštím sprintu
Nemusíte zavádět složitý proces. Začněte třemi jednoduchými kroky:
- Plánujte jen 80 % realistické kapacity. Zbytek nechte na bugy, urgentní práci a nečekané komplikace.
- Zaveďte pravidlo one in, one out. Nová story může vstoupit do sprintu jen výměnou za jiný scope.
- Veďte Sprint Scope Change Log. Každá významná změna sprintu musí být viditelná.
Po dvou až třech sprintech budete mít mnohem lepší data. Uvidíte, jestli tým opravdu špatně plánuje, nebo jestli je hlavní problém v tom, že se sprint průběžně mění. V mnoha případech zjistíte, že tým není pomalý. Jen dlouhodobě absorbuje více práce, než kolik je vidět v původním sprintovém plánu.
Závěr: sprint nemá být nafukovací batoh
Sprint overcommitment není jen plánovací chyba. Je to často důsledek toho, že organizace neumí řídit změny priorit během sprintu. Nové stories, bugy a urgentní požadavky do vývoje patří. Ale nesmí se tvářit, že nezabírají žádnou kapacitu.
Zdravý sprint není ten, do kterého se vejde všechno. Zdravý sprint je ten, ve kterém tým vědomě řídí kapacitu, rizika a změny rozsahu. Pokud do sprintu něco přidáme, musíme se zároveň rozhodnout, co odsouváme. Teprve pak se ze sprintu stává nástroj fokusu, ne nafukovací batoh pro všechny urgentní požadavky.
Pokud ve vašem týmu opakovaně řešíte přeplánované sprinty, vysoký spillover nebo nejasnou predictability, může pomoci nezávislý pohled zvenku. V rámci agilního coachingu pomáháme týmům odhalit skutečné příčiny problémů v plánování, toku práce i řízení priorit – a nastavit změny, které fungují v reálném prostředí, ne jen na papíře.