Jak vypadá Scrum Board

Minule jsem slíbila, že příště poradím, jak by měl vypadat správný Scrum Board, tedy Scrumová tabule. Nic složitého. Základ je, že použít můžete úplně cokoliv. Tabuli, stěnu, skříň, sklo. Nic sofistikovaného. Stačí tři sloupce: Sprint Backlog, In Progress, Done. Tedy to co máte dělat, na čem zrovna pracujete a co už je dokončené. Více sloupců je kontraproduktivní a často v psychologické rovině naopak omezuje týmovou spolupráci. Začínající týmy často používají místo in progress sloupce jako code, test, review, apod. Tím se však jen zuby nehty snaží držet toho, jak pracovaly před agilem. Pochopitelné, ale o moc dál nás to neposune.

Z tabule by mělo být i koutkem oka pro náhodné kolemjdoucí vidět
– jestli tým stihne práci dokončit nebo ne,
– kdo na čem zrovna pracuje,
– a co konkrétně ještě zbývá k dokončení jednotlivých User Stories.

Jestli vám něco z toho chybí, změňte to. Když máte tabuli na papíru, je to snadné a jakákoli změna nezabere víc než pár minut. Můžete argumentovat, že je lepší mít nástroj, ale to pro tabuli rozhodně neplatí.

* Tým se podle takové tabule orientuje, všichni by se v ní tedy měli vyznat. Použít můžete různé barvy pro různé typy aktivit, červeně zvýraznit blokace, klidně i se jménem, na koho že to čekáme.
* Ideální je organizovat User Stories do řádek tak, aby bylo vidět kolik tásků je již hotovo, kolik je rozpracováno a kolik zbývá dokončit.
* Udělejte si pro jednotlivé členy týmu avatara (ideálně jednoho, protože stejně chcete limitovat work in progress a jeden člověk by tak mohl pracovat jen na jednom tásku), ať na první pohled vidíme, kdo na čem zrovna pracuje.

A tady je pár fotek tabulí, které můžu doporučit pro inspiraci:

Kreativitě se meze nekladou :),  je to jen na vás. Takže se můžete podívat, jak v týmech vypadají další tabule. Ne všichni tady dodržují výše popsané principy, ale i tak mohou být dobrým zdrojem inspirace.

A na závěr, na tabuli můžete mít klidně celý Backlog, jako měl jeden krásný startup sídlící v samém srdci NYC. Ti byli opravdu agilní. Celou duší. Vlastně jsem nikdy neviděla lepší agilní kulturu. Tam bych jednou chtěla pracovat 🙂

Proč je Sprint Burndown omyl

Slíbila jsem vysvětlení, proč je Sprint Burndown zbytečným overheadem a co dělat namísto něj. Tedy začněme tím, co by mělo být cílem – a tedy poznat, jestli tým ještě stihne dokončit User Stories, ke kterým se v rámci Sprintu zavázal. Tedy všechno, co je ve Sprint Backlogu. A to co nejjednodušší cestou. Bez zbytečných věcí. Když jsem nad tím přemýšlela, došla jsem k závěru, že většina lidí Sprint Burndown používá prostě proto, že nástroj který si koupili ho umí vykreslit. Tedy upřednostňují nástroje a procesy před lidmi a vztahy mezi nimi. Hned první věta agilního manifestu 🙂
Ale řekněme, že tohle není váš případ, že byste opravdu jen rádi věděli, jestli tým Sprint Backlog dokončí včas. A tak jste si začali takový graf kreslit ručně. A ejhle. Jak takový graf obvykle vypadá? No třeba takhle. Tým pracuje na mnoha User Stories najednou, a než dokončí první, je tu konec Sprintu. A když se Scrum Master v polovině Sprintu zeptá, jestli stihneme všechny User Stories ze Sprint Backlogu, dostane se mu obecného ujištění ve stylu “no jasně”. Nicméně z výše zmíněného Burndown Grafu to vidět není.

Možná namítnete, že váš tým přeci jen něco v průběhu dokončí, pak situace vypadá asi tak takto… ale to v reálu na věci nic nemění. Nezbývá než si držet palce. Nic o výsledku nám takový graf neříká. Jen ukazuje na fakt, že nic nevíme.

A někde tady se rodí myšlenka implementovaná mnoha nástroji, že je pro Burndown graf třeba trackovat jednotlivé úlohy. A abychom měli přehled, začneme je ohodnocovat v čase. Ale pozor, není čas přesně to, čeho jsme se v rámci agilních přístupů snažili zbavit? Na co pak ohodnocujeme v bodech, když tým vzápětí vracíme do světa man-days a hodin? Odhlédneme-li od toho, že založit úlohu v systému stojí nemalý čas týmu, který se členové týmu snaží minimalizovat tak, že zakládají relativně velké úlohy, aby je pak nemuseli měnit, nebo dokonce zahodit. A tyto pak odhadují v hodinách a své odhady kolik času zbývá, každý den mění. A překvapivě, jsme na tom obvykle ještě hůř, než bez takových odhadů. Většinu času si myslíme, že je všechno v pohodě, a ejhle, ono nebylo. Může za to mnoho faktorů, psychologie a optimismus vývojářů či testerů je jedním z nich. Už je to přeci skoro hotové.

No a teď už zbývá jen jeden krok – tedy místo nějakých odhadů prostě jen měřit čas, který jsme na daných User Stories strávili, a ten v grafu zobrazit. A světe div se, dostaneme každý Sprint krásnou lineární křivku, kolik “hodnoty“ tým každý den vyprodukoval. O tom, kdy to bude hotové, takový graf neříká nic, ale zato pěkně vypadá, dá se hezky reportovat a tým může všem dokázat, že poctivě pracoval.
Takže co s tím? Daleko snazší metodou jak zjistit, jestli ještě stihneme dané User Story dokončit, je udělat dobrou a přehlednou Scrum tabuli. Tři sloupce – backlog, in progress, done. Přehledně označit, kdo na čem pracuje, a co je ještě třeba dokončit. Dodržovat best practice tak, že limitujeme work in progress, tedy rozpracovanou práci, snažíme se věci rychle dokončovat a aby to bylo pěkně vidět, rozpadnout User Stories na jednotlivé činnosti o velikosti cca jeden den. Přidat lístek s taskem trvá několik vteřin, zahození ještě méně. Je to snadné, rychlé, efektivní. I náhodný kolemjdoucí koutkem oka z takové tabule vidí, v jakém je to stavu. A to se může hodit. Ušetříte si kupříkladu otravné otázky Product Ownera, jestli to stihnete, ale hlavně, budete sami vědět, na čem opravdu jste. A abych vás nenechala bez návodu, o tabuli, jak ji používat, a jak má vypadat, napíšu zase příště.