Daily stand-up dobre VII – Čo vraví Burndown graf

Burndown graf predstavuje metriku, ktorú je najpotrebnejšie sledovať počas denných stand-upov. Vlastne pred denným stretnutím samotným, lebo snažiť sa pochopiť, čo vraví, až na stretnutí, je už neskoro.

Burn Down graf príklad

Burndown graf

Všetci, ktorí začali s Agile, vedia, že Burndown graf zobrazuje zostávajúcu prácu. Zároveň je to tímová metrika, teda indikuje zostávajúcu prácu nie jednotlivých členov tímu, ale celku. Prečo nás má zaujímať tímový progres a nie osobný?

Nuž spomeňme si na základné princípy fungovania agilného tímu:

  • Multidisciplínnosť.
  • Spoločný cieľ.
  • Spoločný záväzok.
  • Spoločná zodpovednosť.

Dobré agilné tímy spolupracujú veľmi intenzívne a v takomto nastavení sa ulievaci odhalia veľmi skoro. Z pohľadu produktu mňa ako zákazníka člen tímu nezaujíma, zaujíma ma stav produktu ako celku.

Aj keď je Burndown jednoduchý (iba dve čiary), práve tímovosť vedie k zaujímavým situáciám. Aj preto sme vytiahli jeden z našich dávnych článkov, ktoré sme napísali pre časopis Methods and Tools, a pripravili tento skrátený slovenský preklad.

Čo krivky Burndown grafu indikujú

Ideálny tím

Radosť sa pozerať, že? Zostáva približne toľko práce, koľko sme odhadovali. Čo to znamená:

  • Tím odvádza skvelú prácu.
  • Vedia, koľko v iterácii zvládnu.
  • Merajú a evidujú si historické hodnoty, aby vedeli presnejšie odhadovať.
  • Iteráciu stihnú ukončiť.
  • Scrum Master vie správne pracovať s tímom a navigovať ho k dokončeniu úloh.
  • Tím vie reagovať aj na chyby a zmeny uprostred sprintu.

Ak váš graf vyzerá takto do roka, tak si gratulujte. Ste skvelí. Len tak ďalej.

Super tím

Takto vyzerá typický graf tímu, ktorý už má rozbeh Agile za sebou.

  • Tím je zameraný na cieľ a snaží sa ho docieliť.
  • Rozsah sprint backlogu bol upravený tak, aby stihli backlog dokončiť.
  • Tím sa zlepšil ohľadom dokončenia implementácie požiadaviek.
  • Tím sa pýta: „Ako dokončíme tento sprint?“

Napriek tomu, že sú super, je tu menší problém. V poslednej časti sprintu nerobili nič na sprint backlogu. V takomto prípade si mohli vziať ďalšiu user story z produktového backlogu. No možno sa venovali niektorým technologickým dlhom. Aj preto by si mal Scrum Master dávať pozor a najprv overiť, na čom pracovali.

Sebareflexívny tím

Tím má za sebou zvyčajne niekoľko sprintov. Uprostred sprintu prišli na to, že nestačia všetko vyvinúť. Preto sa asi stretli a upravili rozsah sprintu alebo jednoducho začali viac makať.

  • Tím treba pochváliť za proaktívnosť v dosiahnutí hotového výsledku.
  • Sebareflexia tímu indikuje, že v tíme sa vedia dohodnúť.
  • Pravdepodobne dobre spolupracujú aj s produktovým vlastníkom, ktorý dokáže upraviť obsah sprint backlogu.

V nasledujúcom sprinte skúste si vziať na seba menší záväzok tak, aby ste nemuseli meniť svoj pôvodný sľub, čo dodáte.

Bum. Neskoro!

Veľmi typický priebeh hlavne v čase zavádzania Agile.

  • Tím sa potrebuje ešte naučiť, koľko je ich kapacita sprintu.
  • Problém je, že sa nedohodli na zmene rozsahu počas sprintu. Scrum master by mal viac koučovať tím. Produktový vlastník musí viac sledovať tím a zaujímať sa o výsledok.

V podstate žiaden problém. Len dobrý dôvod na poučenie sa. V tomto prípade je to často dobrá téma na retrospektívu. Ako dokončíme to, čo sme sľúbili?

Pozor, niekto ide!

Aj keď neuveriteľný, no aj tak graf z reálnej praxe tímov, ktorý sme videli pri koučingu. Bohužiaľ.

  • Tímu je jedno, že nevedia či sprint stihnú dokončiť alebo nie.
  • Často je to indikácia hlbších problémov vo vzťahoch v tíme.
  • Produktový vlastník sa nezaujíma o priebeh sprintu.
  • Manažment sa nestretol s tímom počas dvoch týždňov.
  • No chyba môže byť aj v niekom, kto napriek neustálej snahe dokončiť položky backlogu pridáva a pridáva nové. A tím sa nehýbe.

Táto situácia je definítivne témou retrospektívy. Posilnite koučing na osobnej úrovni. A požiadajte o dohľad manažmentom, ktorý môže prijať opatrenia či už vo vzťahu k členom tímu alebo ku klientovi, ktorý neustále pridáva prácu.

Chceš chlieb? Tak makaj!

Že to nie je Burndown ale Burnup? Podobá sa, no stále je to Burndown indikujúci zostávajúcu prácu, ktorú tím nemá šancu stihnúť.

  • Produktový vlastník alebo klient neustále pridáva prácu bez opýtania sa tímu.
  • Tím ho to nechá robiť bez eskalácie problému.
  • Scrum Master je asi bezmocný.
  • A čo robí manažment?

Takýto priebeh na grafe sa v praxi skončil dobre. Ľudia dali výpovede, klient, ktorý to robil, zostal bez tímu, dodávateľ riešenia bez referencie a ľudí.

A prečo dobre? Lebo sa rozišli. A to bol jediný rozumný spôsob, ako tento problém vyriešiť po niekoľkých rovnako vyzerajúcich sprintoch.

Vyzerá váš graf inak?

Ďalšie grafy si pozrite v pôvodnom článku na produktovom blogu ScrumDesku. Možno tam nájdete aj váš. Ak nie, tak nám ho pošlite na potrebujemporadit@scrumdesk.com. Pokúsime sa vám pomôcť.

Pokračovanie

Denný standupMetrikyProduct OwnerScrum MasterZlepšovací proces

Mohlo by Vás zaujímať

Ako deliť požiadavky, časť 3: Podľa obchodného pravidla

Ako deliť požiadavky, časť 3: Podľa obchodného pravidla

Komplexné produkty umožňujú paradoxne jednoduchšiu a rýchlejšiu tvorbu produktov. Ak priorizujete požiadavky delené...

Ako deliť požiadavky, časť 2: Podľa operácií

Ako deliť požiadavky, časť 2: Podľa operácií

Počuli ste o user stories splitting? Veľké požiadavky sa majú rozdeliť na menšie. V článku nájdete viacero príkladov...

Ako nepísať požiadavky v Agile: Procesné kroky

Ako nepísať požiadavky v Agile: Procesné kroky

Ako správne písať požiadavky v agile? Typické chyby pri písaní user story. Product ownership zmysluplne....

Novinky

Naše Agiloviny

Nenechajte si ujsť výber toho najlepšieho z Agile, s čím sa stretli naši mentori. Nielen zo sveta produktov, vývoja, tipov a trikov, ale občas aj humoru. Posielame pravidelne, raz za občas :) #QualityOverQuantity

Posielať na