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ě.
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Ja take nejsem priznivcem burndown resp. burnup. Ale pro v clanku uvedene priklady se ten graf docela hodi, protoze nazorne ukazuje procesni problemy.
Chci rict, ze burndown graf nemuze za to, ze se tym lidi rozhodl napr. rozdelat vsechny stories a zadnou nedokoncil. Ale z obrazku kde se krivka neblizi nule je patrne ze je neco spatne. Ale spatny je postup tymu, nikoliv graf.
nojo, je, ale to stejne preci vi kazdy kdo ma oci a hlavu i bez Sprint Burndownu. Tak proc tedy travime cas jeho kreslenim a hlavne vytvorenim podkladu pro to abychom ho nakreslili… Je to v pomeru k hodnote kterou prinasi ta nejdrazsi aktivita 🙂
Ze je nekde problem, asi skutecne vidi kazdy, ale “videt” to spravne reseni vyzaduje hodne zkusenosti. Proto lide kresli grafy, protoze to je jednoduche, hezke, prodava to, a pokud graf nevypada hezky, tak prekresli graf, misto aby “videli” do hloubky problemu.
Stejny osud ale potkava i tabuli, nebo jakykoliv jiny nastroj. Pokud se ukoly nevejdou na tabuli, co je prvni reseni? Zvetsit tabuli – resp. zavest “tabuli” v pocitaci. Pokud je na konci iterace nedodelano, co je prvni reseni? Presunout vsechno do dalsi iterace. 🙂
To, ze je graf vlastne zbytecny a drahy, se prave musi nejdrive poznat tim, ze se zacnou dokoncovat ukoly, tj. opravi se procesni problem. Pak se jako vedlejsi efekt zjisti, ze graf je na ocet.
Ja tedy nevim, ale tymy ktere funguji, maji obvykle tabuli, a jen velmi vyjimecne Sprint Burndown. Naopak tymy, co Scrum delaji jen technicky se v kresleni Sprint Burndownu casto vyzivaji… ale ze vseho jsou samozrejme vyjimky. 🙂 takze jestli vam to nekomu funguje, delejte jak uznate za vhodne :))
Paci sa mi myslienka, ze z tabule je kazdemu jasne ako si tim stoji, kolko prace este ostava. O nieco podobne sa snazime aj u nas. Ide to velmi dobre, ale stava sa, ze nie vzdy to je celkom jasne.
Napriklad mame sprint s 10 US. Z toho 2 US su vacsie – je predpoklad, ze budu trvat viac dni. Ostatne su mensie a v pohode sa daju za den stihnut 2 US a viac. Kazda US ma vzdy 2 tasky (programovaci a testovaci). Cize ked sa v strede sprintu pozrieme na tabulu, moze to vyzerat podla taskov, ze nestihame. Ale v skutocnosti uz ostali iba tie jednoduche US. A aj ked pocet taskov, ktore cakaju na realizaciu je vacsi ako pocet uz dokoncenych, je uplne realne, ze tim to stihne.
To nehovorim, ak si rozdelime US na viac taskov, ktore trvaju menej ako den – preto lebo na kazdom tasku moze robit sucasne niekto iny – snazime sa o co najlepsi W-I-P. Potom uz pocet taskov cloveku, ktory nepozna rozsah uloh, alebo si aspon nepozrie ich body nema tusenie v akom stave je zavazok v strede sprintu.
A este ma napada – chceme sa zbavit casovych odhadov, ale delenie taskov cca na dni nam zase do tohto vnasa svet man-days a hodin.
Opravujem – kazda US ma vzdy minimalne 2 tasky. Cim zlozitejsia US tym viac taskov ma. Cize ked stihneme za den urobit 3 US, tak je to 6 taskov a pritom zlozita US moze mat tiez 6 taskov ale budeme ju robit tri dni …..
Otazkou je, zda opravdu potrebujete delit US na tak drobne kousky jako je pul den – a jaka je pak BV takovych drobnych funkcionalit. A proc potom delite US jeste na vice tasku. To ze je neco test+dev neznamena ze na tom nemuzou pracovat v paru. A nakonec vec co za jeden den dokoncite, nemusite na tasky delit vubec.
US se nedeli na tasky podle dev/tst/… ale na nejake aktivity ktere do pristiho standupu asi stihnete dokoncit… jinymi slovy, chceme aby kazdy standup stacilo rict tenhle papirek dokoncim. A tenhle jsem dokoncil. (tebo klidne tyhle papirky – paklize to ma smysl delit… )
Ony ty US maji body, takze i podle toho se da orientovat…
a ty tasky, neni to o hodinach je to radove na den, kdyz uz tam task vysi vic jak dva dny v IP, tak je asi cas ho rozdelit 🙂
Ludia na projekte sa v tom samozrejme orientuju. Vyberali si ulohy do sprintu, bodovali si ich, maju urcitu predstavu co kazda uloha obnasa. Ja som iba narazal, ze ked pride niekto nezainteresovany, tak nevie presne povedat, ci sa stiha alebo ani nie.
Na delenie taskov na test a dev sme pristupili, aby sme vyriesili jeden dlhotrvajuci problem, ktory sme mali. Ked vyvojar dokoncil nejaky task, ktory sa dal aj testovat tak ho iba oznacil, ze uz sa moze testovat. Samozrejme, ak sa dalo nieco testovat uz od zaciatku, tak na to bol iny task. No a ked oznacil tento task, ze sa moze testovat, tym to pre neho haslo. Uz iba riesil dalsie tasky z inych US. Teraz ked je tam aj testovaci task, tak kazdemu to svieti do oci, ze dana US este nie pred dokoncenim, ale je iba v polovici napr. A hocikto, aj vyvojar ju moze dorazit. Kazdy ako keby mal uchylku siahnut po novej veci. Teraz moze :).
Zrejme sa toto da dosiahnut aj inym sposobom…
Zpusobu je vzdy spousta a co funguje jeden den nemusi fungovat dalsi, takze co funguje si nechte a co ne to zmente :))
Prijdu se na tabuli podivat 🙂
Super, teším sa 😀
Porad nevidim problem v Burndown grafu, ale v tom, ze v prvnim pripade se trackuji US, tech muze byt celkem malo a high level. Nicmene skokem od prikladu jedna ke dva je mezikrok, trackovat tasky, bez nutnosti ohodnocovat je v case.
Tak to delame my, tasky mohou mit svoji effort point vahu, nebo jen vahu 1 a primerenou velikost, pak burndown opravdu odhoriva prubezne.
Ahoj Zuzi. Více méně souhlasím. Také burndown nepoužívám, protože věřím, že otevřená komunikace ukáže problém i bez grafu. Ztotožňuji se ale také s názorem Aichi, pokud někdo chce dělat burndowny, tak pálit po taskách.
Konečnou otázkou ale stejně zůstává jestli je to k něčemu dobré. Pokud členové týmu nejsou zvyklý otevřeně mluvit o tom, že někde drhnou, tak si myslím, že burndown má smysl, protože dává v šanc odhalit rizika, o kterých tým nemluví. Pokud ale členové týmu mluví otevřeně, tak burndown jen duplikuje informace.