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ě.

Nástroje omezují a svazují

Než začnete diskutovat na téma, že nástroje jsou přece užitečné, podívejte se kolem sebe. Kolikrát jste slyšeli, že ten a ten systém je špatný? Že vám nedává to, co byste chtěli? Že musíte používat jeden a raději byste měli druhý? Že nemůžete věci dělat jinak, protože váš nástroj to neumožňuje? A čím větší je firma, tím více procesů a nástrojů vygenerovala. O procesech jsem psala minule, takže těm se pro tentokrát vyhnu. Vzpomínáte si na Agilní manifest? Hned první princip říká “Upřednostňujeme lidi a jejich vztahy před procesy a nástroji”. A přesně v tomto kontextu je to potřeba vnímat. Opravdu upřednostňujete to, co vaše týmy potřebují, před tím, co zrovna musíte používat za nástroj? Viděla jsem spoustu týmů, které implementovali Agile a Scrum tak, že začali hledat nástroj… Nástroj, který jim pomůže být agilní a Scrum nasadit. Ale to není zrovna agilní přístup, že?

Najdete různé pěkné nástroje, které umí mračna zajímavých věcí. A tak týmy, ve snaze využít maximum možností, dělají milióny věcí, které jim nic nepřinášejí a k opravdovému cíli – tedy společně dodat hodnotu pro zákazníka efektivně, rychle a kvalitně – nás nikterak neposouvá. Ba právě naopak. Jsme pak často pomalejší, Scrum se stává divnou byrokracií bez obsahu, a jako takový nepřináší vyšší zapojení jednotlivců, nadšení, ani žádné inovace, ale jen “my teď musíme… “, “my nemůžeme…”, a nebo “my pořád schůzujeme a vyplňujeme”…

Příkladem toho, o čem mluvím, může být třeba ohodnocování tásků hodinami. Výborná praktika, která žere neskutečně času týmu a jediným důvodem pro její vykonávání je to, že náš nástroj pak umí kreslit burndown graf za Sprint… Který však, podíváme-li se na něj čistýma očima, nepřináší nic, co bychom už dávno nevěděli z dobré tabule a funkčních standupů. Sprint burndown je naprostá zbytečnost, která se v agilní komunitě ujala právě proto, že týmy viděly další pěknou věc, kterou jejich nástroj umožňuje, tak proč ji nezkusit, že?

Dalším příkladem jsou různé nástroje, které umožňují vidět tabuli online. A teď ani tak nemluvím o geograficky distribuovaných týmech, ale o lidech, kteří sedí v jedné budově či dokonce místnosti… Na začátku za tím stojí dobrý nápad, my budeme naši tabuli vidět odkudkoliv, nemusíme vstávat, abychom tam udělali změnu… Ale není to náhodou přesně to, čeho se chceme vyvarovat? Co chceme agilním přístupem změnit? Vždyť my přece chceme, aby se tým potkával a povídal si, aby každý mohl vzít tužku a lísteček a hned napsat, co se musí ještě udělat, a když se něco změní, tak prostě lísteček vzít a zahodit, jako by ani neexistoval. Nepotřebujeme historii tásků popsanou do posledního detailu. Nepotřebujeme evidenci všech změn a nápadů, které jsme kdy měli… Chceme si jen být jisti, že jako tým ještě stihneme dokončit všechny User Stories které jsme zákazníkovi slíbili. A nechceme žádnou zbytečnou byrokracii. Zkuste si napsat task na lepítko anebo zadat do systému. První varianta je mnohonásobně kratší a všichni její výsledek vidí kdykoli vzhlédnou nebo jdou kolem na kafe, aniž by museli spustit systém a dát refresh.

A když volně přejdeme k dalšímu přikladu, chceme se flexibilně organizovat… Není tedy cílem vzít User Stories a na začátku Sprintu je přiřadit jednotlivým lidem. A mentálně je za ně udělat zodpovědnými. Tým by měl být za jejich dodání zodpovědný jako celek, ale když se řídíme nástrojem, tak to často nejde. Ano, některé týmy User Stories přiřadí Scrum Masterovi aby nástroji něco předhodili. Ale většina takových řešení funguje psychologicky na backgroundu a ovlivňuje – aniž byste si to uvědomovali – vaše chování. A to i ve věcech, kde byste se hádali do krve, že vás to přeci neovlivní. Že nevěříte? Dělaly se například studie s velkou skupinou lidí. První skupina dostala otázku “Kolik obyvatel má stát Texas?”. Když z odpovědí celé skupiny uděláte průměr, dostanete nějaké číslo. Druhá skupina dostala velmi podobnou otázku – “Kolik obyvatel má stát Texas, je to více než 500 tisíc?” a překvapivě odpovědi byly výrazně bližší číslu 500 tisíc. Experiment se v různých podobách opakoval mnohokrát a pokaždé se stejným výsledkem. Říká se tomu kotvení. A zpět k příkladu s nástrojem, který vás nutí User Story assignovat konkrétnímu členovi týmu. V momentě, kdy to uděláte, zakotvíte zodpovědnost z týmu jako celku k nějakému konkrétnímu členu týmu. A stejně jako u výše zmíněné otázky na obyvatele Texasu, na pozadí to ovlivní chování týmu. Aniž byste si to uvědomili. Je to psychologie chování lidí.

Scrum překvapivě drží pohromadě právě na tom, že jednotlivé praktiky různým způsobem podporují nebo naopak omezují jisté stereotypy chování lidí. Scrum je postaven na psychologii. Bez ní je to jen technický proces, který v praxi pouze vzbudí ohromná očekávání ale výsledek se nikdy nedostaví. Nástroje jsou fajn, ale bez toho, aniž rozumíte psychologii na pozadí Scrum procesu, bez toho aniž byste pochopili Scrum DNA, jsou většinou kontraproduktivní a Scrum a Agile zabíjejí. Velice rychle a chytře. Jsou jak rakovina, která se usídlila v organizmu týmu nebo firmy. Po chvíli se vy přizpůsobujete nástrojům, ne naopak, a to je přesně ta chyba. Používejte nástroje, protože tu jsou od toho aby vám pomáhaly, ale v momentě kdy zjistíte, že něco děláte jen proto, že to nástroj umožňuje, nebo že naopak něco neděláte, jen proto, že to nástroj neumožňuje, zastavte se a zamyslete se kdo má koho pod kontrolou. Vy nástroj, nebo nástroj vás. A v prostředí, ve kterém lidi a týmy řídí nástroje, se lidem moc nedaří.

Burndown grafy

Sice už jsem tu párkrát o burndown grafech psala, ale nedávno jsem rozšířila a opravila původní template, a nakonec, opakování je matka moudrosti, tak ho tu popíšu ještě jednou.

Microsoft Excel Scrum Burndown template najdete zde.

A teď k popisu jednotlivých záložek. Na prvním obrázku je reprezentace product backlogu. V levé části jsou definovány jednotlivé Super User Story a User Story, spolu s ohodnocením. V pravé části je zaznamenán progress na konkrétní User Story v daném Sprintu.

backlog-representation

V další záložce se vlastně všechna data počítají. Jediné co musíte udělat je každý Sprint vyplnit aktuální hodnoty do sloupce C a D – Data from Backlog (Points Remaining Velocity a Actual Points Complete). Zároveň před začátkem projektu nastavit očekávanou rychlost týmu a buffer / očekávaný přírůstek bodů za sprint – sloupce K a L (Plan: Planned Velocity a Planned New Points (Buffer)). Chcete-li sledovat i jak se Vám posouvá datum konce projektu, vyplňte si na začátku projektu i v Planned Date sekci sloupec F (Target Date) a každý Sprint aktuální predikci v Planned Date sekci sloupec E (Projected Completion Date). Všechno ostatní se počítá a kreslí za Vás.

burndown-data

A následují grafy. První z nich sleduje plánovanou rychlost týmu a porovnává ji s aktuálními hodnotami, kterých tým byl schopen dosáhnout.

burndown-velocity-rychlost-graf

Další graf zobrazuje klasický burndown graf rozšířený o predikce kdy očekáváme, že bude projekt hotový. V jednoduchosti řečeno, pokud se pohybujete mezi tečkovanými čárami, běží vše podle očekávání.

burndown-graf

Poslední graf který v souboru najdete Vám ukazuje jak se v čase měnilo předpokládané ukončení projektu.

burndown-project-completion-date

Scrum v extrémních podmínkách

Vraťme se k otázce pro jak velký tým a v jakých podmínkách lze Scrum proces použít. Ráda bych se podělila o svou poslední zkušenost se zaváděním Scrum procesu v té nejminimálnější představitelné podobě. Jak si poradit s krátkými projekty v řádu několika dní a týmu o velikosti jednoho člověka? První intuitivní odpověď je, že na Scrum můžete zapomenout. Všechny projekty by vlastně byly hotovy v rámci jednoho Sprintu, a tedy by to asi nemělo moc smysl. Jak ale zařídit abychom vždy přesně věděli, kde jsme a mohli rychle reagovat na třeba i drobné zpoždění a problémy? Zvlášť když zpoždění jeden den už může být pro úspěch projektu kritické.

Řešení je nasnadě. Nic nám vlastně nebrání Scrum proces použít, jen se musí vhodně upravit délka Sprintu. Prvním úkolem bylo vytvoření Backlogu. Jednotlivé úlohy, ohodnoceny body, byly rozděleny na celky v řádu pár hodin. Délku Sprintu jsme nastavili na půl dne. V takto krátce nastaveném Sprint cyklu už se nic neschová. Žádný delší oběd, ranní káva, ani problém se špatným ohodnocením úloh. Nic. Ale na druhou stranu, alespoň máte informace o tom, že projekt zítra nebude, již dnes v poledne. A tedy můžete zareagovat. Vyžádat si pomoc kolegy, zavolat zákazníkovi a domluvit si pozdější dodání. Pořád lepší než volat zpětně že jste to zase nestihli.

Takže jak to vypadá v praxi. Každý pátek se udělá plán na následující týden. V kalendáři rezervace času na jednotlivé projekty. Pro všechny týmy (i když tým o jednom člověku moc týmem není). Každý půlden se potom updatují Burndowny jednotlivých projektů, a případně kalendář, abychom věděli, proč se plán změnil. Docela hodně drsné. Ale hlavně, funguje to naprosto skvěle. Vzhledem k rychlosti výroby produktu, je to ale asi jediná možnost. Scrum meeting asi stačí jednou denně, na prodiskutování progresu a plánu na následující den.

Ještě jedna věc. Přesunuli jsme Burndowny na GoogleDocs, na změnu máme nastavené automatické emaily a tak stačí jen sledovat na mailu co se děje.

GoogleDocs, Backlog a Burndown Graf

O tom k čemu využít Burndown graf už jsme psala v minulém příspěvku. Template pro Microsoft Excel je k dispozici také. Nicméně takový Excel se špatně sdílí mezi distribuovanými týmy. Jednou z možností je použití nějakého komplexního online systému, ale to s sebou obvykle nese další výdaje na licence a často i omezení Vašeho procesu.

Dobrým řešením je použít GoogleDocs. Tady je jako public příklad, jak by mohl Burndown vypadat (http://spreadsheets.google.com/ccc?key=p8oML5C9M–uwofmhl1npew).

První list obsahuje Produkt Backlog. Každý Sprint se zaloguje kolik bodů se udělalo, a kolik ještě zbývá.

Tyto hodnoty je následně nutné přenést do oranžově orámované části. Zbytek už se dopočítá automaticky.

Velocity Graf je prvním ze série grafů. Červená oblast zobrazuje počet bodů, které by tým měl stihnout za jeden dané Sprinty. Modrá křivka odpovídá aktuálním výsledkům.

Dalším grafem je tradiční Burndown Graf, který modře zobrazuje, kolik bodů ještě zbývá, oranžově kolik se již dokončilo a červeně případné změny bodového hodnocení (viz řádky 10, 11 v Backlogu).

Poslední graf zobrazuje Burndown z pohledu očekávaného dokončení projektu. Modrá křivka zobrazuje aktuální počet bodů, co zbývá dokončit, červená je potom projekcí ukončení projektu. Obecně se dá říct, že pokud je modrá a červená křivka uvnitř oranžové a zelené oblasti, očekávaný konec projektu je stále v rámci projekt bufferu a vše je v pořádku.

Burndown graf template

Jak na Burndown? Možností je několik. Můžete začít provozovat jeden z mnoha systémů na Scrum proces a Burndown graf se vám bude zobrazovat víceméně sám od sebe, v jedné z mnoha podob. Systémy jsou komplexní, většinou placené a ne vždy plně odpovídají Scrum procesu tak, jak by se vám hodil. Flexibilita je relativně nízká, obvykle se musíte přizpůsobit vy. Za ty nejznámější vybírám ScrumWorks, ScrumDesk, Rally, Version One. Detailně se jim budu věnovat příště.

Druhou možností je, že si napíšete vlastní Burndown v Microsoft Excelu.

Já osobně tuto možnost preferuji. Za prvé, je to transparentní, přesně víte, co zobrazujete a jak, máte to pod kontrolou. Přikládám pro inspiraci svůj XLS Burndown template. Nic složitého. První sheet obsahuje kopii produkt backlogu s vyhodnocením bodů přes jednotlivé sprinty. Druhý sheet obsahuje výpočty pro grafy. Každý sprint se do něj přenesou dvě hodnoty z sheetu Backlog – Points Remaining a Velocity (Actual Points Complete). Zbytek se počítá sám. Na začátek projektu ještě musíte naplánovat rychlost týmu a buffer do kolonek – Planned Velocity a Planned New Points (Buffer). Další dvě záložky už zobrazují grafy: Project Velocity Plan a Burndown.

Burndown graf

Burndown graf je výborným pomocníkem při vizualizaci výsledků. Na internetu najdete spoustu odkazů jak takový burndown může vypadat, spousta aplikací pro Scrum proces vám je budou přímo generovat. Nicméně obyčejný Microsoft Excel vám udělá stejně dobrou a možná i lepší službu. Výhodou je že se data zpracujete a zobrazíte sami, tedy máte výstup plně pod kontrolou. V tom úplně nejjednodušším případě kdy máte backlog definovaný v Excelu spolu s výsledky jednotlivých Sprintů (třeba takto) je již vcelku snadné data zobrazit.

Důležité jsou v podstatě dva grafy. Jedním je tzv. Velocity plan, tedy plán jak rychle bude tým postupovat. Obvykle vezmete v úvahu, že na začátku se tým učí a pak už pracuje konstantní rychlostí. Je dobré zahrnout do plánu i masivní dovolené (např. Vánoce) a plán tomu pro daný Sprint uzpůsobit.

velocity plan

Druhým grafem je Projekt Burndown graf, který kombinuje aktuální stav s odhady a vizualizuje předpokládaný konec projektu.

Vytiskněte každý sprint tyto dva grafy a vystavte je na veřejné místo, ať všichni na první pohled vidí jak se projektu a týmům daří.

Podívejte se na příklad toho, jak by takový burndown mohl vypadat.

Produkt Backlog a ohodnocení úloh

Na začátku každého projektu je nutné nějak formálně popsat požadavky na systém. Co se má vlastně udělat a jak. Přepsat uživatelské požadavky do trochu techničtějšího popisu, takže mu budou vývojáři rozumět. Agile v tomto kontextu pracuje s pojmem Backlog.

Jak by měl takový backlog vypadat a do jakých detailů by měly úlohy zacházet? Řekněme, že to záleží na fázi projektu. Na začátku je nutné identifikovat high-level oblasti – Story, přidat odhad ohodnocení a základ backlogu je hotov. V průběhu projektu, jak budete vědět více, se Story budou postupně rozpadat na jednotlivé konkrétnější úlohy ohodnocené v rámci původního odhadu a backlog získá více detailů. Samozřejmě se může stát, že některé Story se budou muset přidat a některé se ukážou nadbytečnými.

Takto nadefinovaný backlog tedy pokrývá veškeré aktivity na projektu, spolu s ohodnocením je základním vstupem pro odhady celkové náročnosti. Zároveň je to prvním kamínkem do mozaiky Burndownu, ale o tom až později.

V této podobě (tabulka v Excelu) se nám vyplatilo sledovat jen relativně high-level úlohy. Pro popis detailů jednotlivých úloh či jejich stavu je vhodné použít některý z online trackovacích systémů – jako je třeba Mantis. Pro větší názornost a zpětnou kontrolu odpracovaných bodů jsme posléze přidali pravou část tabulky znázorňující, v kterém sprintu se pracovalo na které úloze.