Šablona agendy plánování sprintu pro vývojářské týmy

Proč se sprinty přetěžují

Plánování sprintu má jedno strukturální selhání, kterému šablony nezabrání: týmy vyberou backlog sprintu ještě předtím, než kdokoli zkontroluje kapacitu. Výsledkem je sprint, který na tabuli vypadal splnitelně a do středy se zhroutí, když jsou dva inženýři půl týdne mimo, jeden tiket ztrojnásobí rozsah a tři položky měly nevyslovené závislosti na službě, kterou platformový tým přepisuje.

Náprava je jednoduchá a téměř nikdy se nedělá: zavažte se ke kapacitě dříve, než se zavážete k práci. Šablona níže právě z tohoto důvodu otevírá kontrolou kapacity.

Agenda (zkopírujte a vložte)

Trvání: 2 hodiny pro dvoutýdenní sprint; 1 hodina pro jednotýdenní sprint
Formát: moderované, s backlogem viditelným celému týmu

Sekce 1 — Cíl sprintu (10 min)

Jedna věta: jak vypadá úspěšný sprint zvenčí?
Cíl by měl být dost konkrétní, aby kdokoli z týmu mohl na konci sprintu vyhodnotit, zda jste ho zasáhli
Odmítejte cíle, které jsou jen seznamem tiketů („dokončit refaktoring auth a stránku fakturace“) — to je backlog, ne cíl

Sekce 2 — Kontrola kapacity (15 min)

Vyjmenujte každého člena týmu jménem
U každého: plánované volno, pohotovostní rotace, pravidelné schůzky, známé externí závazky
Vyjádřete kapacitu jako dostupné story pointy nebo dny — ne jako počet lidí
Toto číslo je strop; nevybírejte víc práce, než unese

Sekce 3 — Výběr z backlogu (45 min)

Projděte položky s nejvyšší prioritou ze zpřesněného backlogu
U každého kandidáta: má tým dost na to, aby to začal, nebo jsou tu otevřené otázky, které potřebují odpovědi před začátkem sprintu? Otevřené otázky patří do fronty na zpřesnění, ne do sprintu
Přestaňte vybírat, když narazíte na 80 % kapacity; zbývajících 20 % absorbuje přetečení a neplánovanou práci

Sekce 4 — Akceptační kritéria (20 min)

U každé vybrané položky: uveďte kritérium, které z ní dělá hotovo
Pokud tým neumí kritérium uvést za 60 sekund, tiket není dost zpřesněný — vraťte ho do backlogu
Napište ho do tiketu hned, v místnosti; nespoléhejte na „přidáme to později“

Sekce 5 — Rizika a závislosti (15 min)

Co by mohlo zablokovat dodání cíle sprintu a co tým neovládá?
Pojmenujte vlastníka závislosti; vyneste ji na povrch teď, dokud je čas ji vyřešit před polovinou sprintu
Nevyřešené závislosti dostanou jmenovaného vlastníka z týmu, který je bude sledovat

Závěr (15 min)

Potvrďte, že cíl sprintu je vzhledem k vybrané práci stále platný
Přiřaďte zapisovatele shrnutí sprintu, nebo potvrďte nastavení automatického reportu
Potvrďte datum příštího plánování

Co většině šablon plánování sprintu uniká

Nejpopulárnější šablony plánování sprintu se zaměřují na údržbu backlogu a definici hotového. Obojí je důležité. Ani jedno neřeší chybu v plánování, která plodí nejvíc selhání sprintů: výběr práce bez kontroly dostupnosti.

Tým pěti inženýrů na plné kapacitě má zhruba 200 story pointů dostupných na dvoutýdenní sprint. Tým pěti, kde jsou dva inženýři na dovolené, jeden rotuje v pohotovosti a jeden je na třídenním offsitu, má možná 110. Pokud v tom druhém sprintu vyberete 180 pointů, už jste selhali. Krok výběru je místo, kde k přeslibování dochází, a kapacita mu musí předcházet.

Druhou mezerou jsou akceptační kritéria. Týmy plánováním prosviští rychle a zamýšlejí kritéria napsat později. Později se to nestane na stejné úrovni konkrétnosti. Člověk, který by v místnosti napsal přesné kritérium, napíše druhý den z paměti něco mlhavějšího, nebo to nenapíše vůbec. Neshody uprostřed sprintu o tom, co znamená „hotovo“, se téměř vždy dají vystopovat k přeskočeným akceptačním kritériím při plánování.

Nabalující se náklady těchto mezer — přetížené sprinty, objevy uprostřed sprintu, znovu otevírané definice — se zřetelně projeví, když si to sečtete: Daň za schůzky.

Proč jsou poznámky z plánování sprintu těžší, než vypadají

Plánování sprintu generuje víc informací než téměř kterákoli jiná pravidelná schůzka: cíl sprintu, čísla kapacity, zdůvodnění výběru položku po položce, akceptační kritéria u každého tiketu, vlastníky závislostí, rizikové položky. Napsat užitečné shrnutí vyžaduje zachytit to všechno ve formě, která je použitelná o tři dny později, když se někdo zeptá „proč jsme tu položku vyřízli?“.

Pavleur vygeneruje report z plánování sprintu automaticky na konci hovoru. Zachytí cíl sprintu, vybraný backlog se zdůvodněním, akceptační kritéria tak, jak byla na schůzce vyslovena, a vlastníky závislostí tak, jak byli jmenováni. Pokud někdo sdílel obrazovku s backlogem nebo tabulkou kapacity, je ten vizuál zahrnut v reportu vedle diskuse — kontext, který by nástroje jen na zvuk jako Otter nebo Fireflies zcela minuly. Kdokoli se přidal později nebo si potřebuje uprostřed sprintu ověřit rozhodnutí, má úplný záznam. Pro srovnání, jak se to liší od nástrojů jen na zvuk: Pavleur vs. alternativy.

Zvládání změny plánu uprostřed sprintu

Plán sprintu je závazek, ne smlouva. Když něco uprostřed sprintu skutečně zneplatní plán — produkční incident, kritická závislost blokující tři tikety, změna priorit od vedení — správnou reakcí je rychlý přeplánovací hovor, ne tiché zahození rozsahu. Přeplánovací hovor zabere 20 minut a vyprodukuje aktualizovaný cíl sprintu, který odráží realitu. Alternativou je sprint, který na papíře selže, ale neformálně se upraví způsoby, které si nikdo nezapsal, čímž se ztíží retrospektiva a čísla velocity ztratí smysl.

Vypěstujte si návyk výslovného přeplánování. Použijte stejnou strukturu: aktualizovaná kapacita, revidovaný výběr, znovu vyslovený cíl. Zabere to mnohem méně času než zmatek, kterému předejde.