Šablóna agendy plánovania sprintu pre inžinierske tímy

Prečo sa sprinty preťažujú

Plánovanie sprintu má jedno štrukturálne zlyhanie, ktorému šablóny nezabránia: tímy vyberú backlog sprintu skôr, než ktokoľvek overí kapacitu. Výsledkom je sprint, ktorý na tabuli vyzeral dosiahnuteľne a rozpadne sa v stredu, keď sú dvaja inžinieri pol týždňa preč, jednému tiketu sa strojnásobí rozsah a tri položky mali nevyslovené závislosti od služby, ktorú platformový tím prepisuje.

Riešenie je jednoduché a takmer nikdy sa nerobí: zaviažte sa ku kapacite skôr, než sa zaviažete k práci. Nižšie uvedená šablóna otvára hodnotením kapacity presne z tohto dôvodu.

Agenda (na skopírovanie)

Trvanie: 2 hodiny pri 2-týždňovom sprinte; 1 hodina pri 1-týždňovom sprinte
Formát: moderované, s backlogom viditeľným pre celý tím

Sekcia 1 — Cieľ sprintu (10 min)

Jedna veta: ako vyzerá úspešný sprint zvonka?
Cieľ by mal byť dostatočne konkrétny na to, aby ktorýkoľvek člen tímu dokázal na konci sprintu vyhodnotiť, či ste ho dosiahli
Odmietajte ciele, ktoré sú len zoznamom tiketov („dokončiť refaktor autentifikácie a stránku fakturácie“) — to je backlog, nie cieľ

Sekcia 2 — Hodnotenie kapacity (15 min)

Vymenujte každého člena tímu po mene
Pri každom: plánované PTO, on-call rotácia, pravidelné porady, známe externé záväzky
Vyjadrite kapacitu v dostupných story pointoch alebo dňoch — nie v počte hláv
Toto číslo je strop; nevyberajte viac práce, než unesie

Sekcia 3 — Výber z backlogu (45 min)

Prejdite položky s najvyššou prioritou z upratovaného backlogu
Pri každom kandidátovi: má tím dosť na to, aby to začal, alebo sú tam otvorené otázky, ktoré potrebujú odpovede pred začiatkom sprintu? Otvorené otázky patria do fronty na upratovanie, nie do sprintu
Prestaňte vyberať, keď dosiahnete 80 % kapacity; zvyšných 20 % pohltí presahy a neplánovanú prácu

Sekcia 4 — Akceptačné kritériá (20 min)

Pri každej vybranej položke: uveďte kritérium, ktoré ju robí hotovou
Ak tím nedokáže uviesť kritérium do 60 sekúnd, tiket nie je dosť upratovaný — presuňte ho späť do backlogu
Zapíšte ho do tiketu teraz, v miestnosti; nespoliehajte sa na „dodáme to neskôr“

Sekcia 5 — Riziká a závislosti (15 min)

Čo by mohlo zablokovať dodanie cieľa sprintu a tím to nemá pod kontrolou?
Pomenujte vlastníka závislosti; vyneste ju na povrch teraz, kým je čas ju vyriešiť pred polovicou sprintu
Nevyriešené závislosti dostanú menovaného vlastníka z tímu, ktorý ich bude sledovať

Záver (15 min)

Potvrďte, že cieľ sprintu je vzhľadom na vybranú prácu stále platný
Priraďte zapisovateľa zhrnutia sprintu, alebo potvrďte nastavenie automatizovanej správy
Potvrďte dátum ďalšieho plánovania

Čo väčšina šablón plánovania sprintu prehliada

Najpopulárnejšie šablóny plánovania sprintu sa sústreďujú na upratovanie backlogu a definíciu hotového. Oboje je dôležité. Ani jedno neadresuje plánovaciu chybu, ktorá produkuje najviac zlyhaní sprintu: výber práce bez overenia dostupnosti.

Tím piatich inžinierov na plnej kapacite má približne 200 story pointov dostupných na 2-týždňový sprint. Tím piatich s dvomi inžiniermi na PTO, jedným v on-call rotácii a jedným na trojdňovom offsite má možno 110. Ak v druhom sprinte vyberiete 180 pointov, už ste zlyhali. Krok výberu je tam, kde dochádza k prepísaniu, a kapacita mu musí predchádzať.

Druhou medzerou sú akceptačné kritériá. Tímy sa plánovaním preženú rýchlo a majú v úmysle napísať kritériá neskôr. Neskôr sa nedeje na tej istej úrovni konkrétnosti. Človek, ktorý by v miestnosti napísal presné kritérium, napíše na druhý deň z pamäti niečo vágnejšie, alebo to nenapíše vôbec. Nezhody uprostred sprintu o tom, čo znamená „hotové“, sú takmer vždy vystopovateľné k vynechaným akceptačným kritériám v plánovaní.

Nabaľujúce sa náklady týchto medzier — preťažené sprinty, objavy uprostred sprintu, opätovne otvárané definície — sa zreteľne prejavia, keď si to spočítate: Daň za porady.

Prečo sú poznámky z plánovania sprintu ťažšie, než sa zdá

Plánovanie sprintu generuje viac informácií než takmer ktorákoľvek iná pravidelná porada: cieľ sprintu, čísla kapacity, odôvodnenie výberu položku po položke, akceptačné kritériá na tiket, vlastníkov závislostí, rizikové položky. Napísanie použiteľného zhrnutia si vyžaduje zachytiť to všetko vo forme, ktorá je použiteľná o tri dni neskôr, keď sa niekto opýta „prečo sme tú položku vypustili?“.

Pavleur vygeneruje správu z plánovania sprintu automaticky na konci hovoru. Zachytí cieľ sprintu, vybraný backlog s odôvodnením, akceptačné kritériá tak, ako zazneli na porade, a vlastníkov závislostí tak, ako boli pomenovaní. Ak niekto zdieľal na obrazovke backlog alebo tabuľku kapacity, tento vizuál je zahrnutý v správe vedľa diskusie — kontext, ktorý by výhradne zvukové nástroje ako Otter alebo Fireflies úplne prehliadli. Ktokoľvek, kto sa pridal neskoro alebo si potrebuje uprostred sprintu overiť rozhodnutie, má kompletný záznam. Pre porovnanie toho, ako sa to líši od výhradne zvukových nástrojov: Pavleur vs. alternatívy.

Zvládanie zmeny plánu uprostred sprintu

Plán sprintu je záväzok, nie zmluva. Keď niečo uprostred sprintu skutočne zneplatní plán — produkčný incident, kritická závislosť blokujúca tri tikety, zmena priorít od vedenia — správnou reakciou je rýchly hovor na preplánovanie, nie tiché vypustenie rozsahu. Hovor na preplánovanie trvá 20 minút a vyprodukuje aktualizovaný cieľ sprintu, ktorý odráža realitu. Alternatívou je sprint, ktorý na papieri zlyhá, ale bol neformálne upravený spôsobmi, ktoré si nikto nezapísal, čím sa sťaží retrospektíva a čísla rýchlosti stratia zmysel.

Vybudujte si zvyk výslovného preplánovania. Použite tú istú štruktúru: aktualizovaná kapacita, revidovaný výber, znovu uvedený cieľ. Zaberie to oveľa menej času než zmätok, ktorému predíde.