Tag: planning

Jak naplánovat Sprint bez odhadů?

Jeden z nejčastějších nešvarů Scrum implementací je odhadování tásků v hodinách a jejich následné poměřování vůči kapacitě týmu. Je to krásná myšlenka, ale v praxi je to nesmysl, který trvá zbytečně dlouho a nic nepřináší. Snad jen to, že můžete nakreslit další zbytečnost – Sprint Burndown.

Myšlenka vychází z nepochopení Scrumu. Je to pozůstatek tradičního myšlení Organizace 1.0 kde jsme věřili, že lidi alias zdroje jsou stejně jen líná banda individuí, kteří když je nebudeme hlídat, tak nic neudělají. Scrum dává práci mnohdy ztracený smysl a tak generuje daleko motivovanější lidi, kteří se sami zlepšují a vymýšlejí jak dělat věci lépe. A kteří toho udělají víc i bez mikromanagementu a detailního vykazování.

Když tedy přestaneme odhadovat kvůli kontrole lidí v týmu, zbývá se podívat, jestli mohou být takhle detailní odhady přínosné týmu samotnému. Podívejme se nejprve na reálnou přesnost takových odhadů. V podstatě, každý odhad je jen jakási předpověď. Slovní spojení ‘přesný odhad‘ je oxymoron. Nemůže nastat. Proto také ve Scrumu neodhadujeme, kdy bude jedna konkrétní věc hotová, ale kolik Product Backlog Items se nám vejde do Sprintu. Nečekané vlivy, které se týmu za Sprint stanou, se tím zprůměrují. Každá individuální story může být výrazně jiná, než jsme čekali, ale v globálu to vyjde. Jedna bude náročnější, jiná snazší, někde se zasekneme, jinde to půjde lépe, než jsme čekali a obavy se nenaplní. Jediné, co je pro plánování Sprintu potřeba, je dobré porozumění Backlogu a jednotlivým Stories. Nikdy bychom neměli do Sprintu plánovat věci, kterým nerozumíme – ale v takovém případě ani pokus o odhady tásků nepomůže.

Praktika, která týmům pomůže porozumět položkám Backlogu a na základě toho je naplánovat do Sprintu je rozpadnout Stories na tásky/aktivity, o kterých věří, že je dokáží dokončit za maximálně den (tedy od Standupu do Standupu). Některé takové tásky budou trvat třeba i tři, čtyři dny, jiné tým dokončí za pár hodin. Není důležité zkoumat tyto výjimky, ty se stanou, ať budete dělat, co budete dělat. A jestli to nejsou výjimky a všechny tásky se ukázaly být příliš malé nebo příliš velké, příští Sprint to napravte tak, aby byly v průměru dokončitelné za den. Je to zdánlivě to samé, také odhadujeme, ale je ohromný rozdíl, jestli na takovou tásku napíšete 8h a nebo se jen každý Standup z odstupu podíváte na vaší Scrum tabuli a zhodnotíte celková posun týmu. Není třeba nic počítat. Scrum je empirický proces, koriguje se sám. Někde začněte a uvidíte. Obecně je nejlepším odhadem včerejší počasí. Stačí naplánovat tolik položek Backlogu, kolik jste dokončili minule. Co se tásků týče, když vám rozpadlé aktivity vyjdou na tak cca na polovinu dní, bude to tak akorát. Obvykle se totiž některé tásky v průběhu rozpadnou na menší kousky a jiné vzniknou. To je zcela normální, neboť řešení vniká teprve v průběhu Sprintu. Zkuste to a uvidíte, jak to půjde. Příští Sprint můžete cokoli změnit tak, abyste našli správný balanc a rytmus.

Planning meeeting na 30 minut – část 2

Jak jsme již říkali v minulém článku, celý Planning meeting se komfortně vejde do 30ti minut. Pojďme se tedy podívat, jak vypadá jeho druhá část. Tým má vybrané User Story na tabuli a v rámci této fáze rozpadá jednotlivé funkcionality na konkrétní činnosti, které nebudou podle jejich předpokladu větší, než aby šly dokončit v rámci jednoho dne.

Na rozpadu pracuje celý tým najednou a paralelně plní tabuli lístečky s jednodenními tásky. Když jednotliví členové týmu rozpad dokončí, společně revidují, jestli na něco nezapomněli. Stejně jako v minulém případě, je dobré se podívat kolik tásků na tabuli vzniklo. Obecně platí, že User Story s vyšším ohodnocením se rozpadá na více drobných aktivit než menší User Story.

Ale není to matematika. Jestli jste naplánovali Sprint Backlog, kde počet lístečků odpovídá práci týmu na dva dny, máte buď příliš nízký commitment, nebo jsou jednotlivé tásky výrazně větší než jeden den, a nebo vám některé aktivity zcela chybí. Naopak, naplánovali-li jste tásků stejně jako je dnů*počet členů týmu, máte vysokou pravděpodobnost, že to nestihnete. Vždycky se něco protáhne a na něco jsme vždy zapomněli. Polovina tohoto čísla může být reálná.

Když jako tým souhlasíte s rozpadem, podíváme se ještě jednou na výsledný Sprint Backlog a eventuálně ho upravíme (přidáme / ubereme nějakou User Story) a o výsledném commitmentu informujeme Product Ownera.

Nutnou podmínkou takového rychlého Planningu je dobrá příprava. Tým nesmí vidět User Story poprvé na Planningu – už se s nimi dobře seznámil na Backlog Groomingu, kde je i ohodnotil. Zanedbat se nesmí ani příprava na rozpad User Stories na jednotlivé aktivity. Tým zná prioroty pro další Sprint několik dní dopředu a může si tak zavčas popovídat o řešení a připravit se na jejich rozpad.

Zkuste a uvidíte, že to není zas tak těžké, a že to funguje. A navíc, jako bonus ušetříte spoustu času a získáte kvalitnější Sprint commitment.

Planning meeeting na 30 minut – část 1

Často s týmy diskutuji na téma, že Scrum jsou jen samé meetingy. A tak začínám tím, že s nimi projdu, jak mají být jednotlivé meetingy dlouhé. Většinou se zasekneme na Planningu, který byste měli v pohodě zvládnout za 30 minut. Jak takový planning vypadá? Tým si nejdříve v cca 15 minutách vybere, které User Story z priorit Product Ownera by mohl dokončit. Ideální je, když opravdu fyzicky vybírá, které z kartiček na stole dá na svoji Scrum tabuli. Jednotlivé User Story a jejich business hodnotu si může tým ještě upřesnit s Product Ownerem, ale výběr je na nich.

Je tedy nasnadě, že jich Product Owner musí přinést dostatek, aby bylo z čeho vybírat. Tým tím přebírá větší zodpovědnost, a také musí produktu po všech stránkách více rozumět, než když jen bere User Stories jednu po druhé podle přesných priorit Product Ownera. Zároveň je to také často efektivnější, protože tým může vybrané User Story přizpůsobit svým zkušenostem a znalostem a optimalizovat tak dokončenou funkcionalitu v rámci priorit Product Ownera.

Fyzická reprezentace ve formě kartiček jako obvykle pomůže. Usnadňuje to týmu převzít kolektivní ownership a zodpovědnost za výběr. Jak jednotliví členové týmu navrhují, které User Stories by tým mohl stihnout, někde se to ve výběru zastaví. A členové týmu si již nejsou jisti, jestli by další věc stihli nebo ne.

Tým si může ještě udělat rychlá cross-check obvyklé velocity, když vyšlo řádově jiné číslo, tak je to dobrý indikátor k zamyšlení se, co nás vede k tomu, že toho tentokrát stihneme dvojnásobek, nebo naopak polovinu, a případné revizi návrhu Sprint Backlogu.

Tady první část Planningu končí, Product Owner i Scrum Master nechávají tým pokračovat druhou 15ti minutovou částí a odchází.

Jako včerejší počasí

Na jednoduchý problém existuje jednoduchá pomoc. Tým neustále overcommituje. Tedy slíbí sedm User Stories a dodá čtyři. Příští Sprint slíbí osm a dodá jen tři, další se zaváže dodat sedm a dodá pět. A tak to pokračuje Sprint po Sprintu. Když se zeptáte co s tím tým dělal, obvykle odpoví, že to řešili na retrospektivě a že příště už se to povede.

Jak dobře odhadovat, kolik se nám toho vejde do Sprintu? Tak předně věřte tomu, že obvyklé věci se dějí obvykle a výjimečné jen výjimečně. Tedy, že když několik sprintů za sebou dodáváte méně, než plánujete, tak se tak asi bude dít i v budoucnu. Důvody pro to se mohou různit, ale na úrovni týmu a Sprintu to vždycky vyjde.

Existuje rychlá medicína. Příští Sprint si do Sprint Backlog vezměte přesně tolik, kolik jste minule stihli dokončit. Takzvaně “včerejší počasí“. Ostatně říká se, že kdyby předpověď počasí byla dělaná podle včerejšího dne, že bude přesnější, než když se ji snažíme odhadovat. Nevím, jak s počasím, ale tady to funguje a výsledek se dostaví okamžitě. A teď, když už to umíme, tak se můžeme pozvolna zaměřit na to, jak rychlost týmu zvednout. Je to první úspěch a na tom se dá stavět. A můžete začít tím, že ho společně zajdete oslavit.