Jak dělat Backlog Refinement

Když už jsme prošli všechny Scrum Eventy, zbývá se ještě zastavit u Backlog Refinementu. Některé firmy mu říkají Grooming, ale na jménu nakonec nesejde. Cílem je vytvořit Product Backlog v rozumné granularitě aby byl vidět výhled a tým měl připravenou práci na dva až tři Sprinty dopředu. Víc není potřeba, nebylo by to přehledné. A protože kažný Sprint tým několik položek Backlogu dokončí, musí každý Sprint několik větších kusů rozpadnout na menší a důležitější. Backlog Refinement tedy běží průběžně, tak jak je potřeba.

Klíčem k úspěchu je si uvědomit že Refinement je hlavně o spolupráci. Položky backlogu by nikdy neměly vznikat v izolaci. Tedy nepíše je Product Owner a nepředává je hotové týmu jak si někteří často myslí, ale je to o spolupráci a spoluvytváření. Kdo tedy položky backlogu píše? Všichni. Product Owner, zákazníci, stakeholdeři a členové týmu kterým ve Scrumu říkáme developers – tedy business analytici, developeři, testeři, designéři, … . Refinement probíhá různě. Někdy pozvete všechny na workshop, kde společně rozmyslí a rozpadnou několik položek backlogu, někdy se sejde jen pár členů týmu a spolu se zákazníkem začnete nějakou oblast popoisovat, a přemýšlet o potřebách které musí pokrýt. Jindy menší skupinka nějakou část produktu rozpadne na menší a jasnější kousky. Není to ani pravidelně naplánovaná aktivita tedy Scrum Event, není ani centralizovaná. Naopak. Zůčastní se ti co se potřebují zúčastnit, v čase, kdy je to potřeba. Ad hoc. Velmi agilní. Nicméně na konci dne musí celý Scrum tým rozumět jednotlivým položkám backlogu v dané granularitě a chápat jejich priority. Refinement tedy potřebuje jako pre-requisitu self-managing cross-funcitional tým. Self-managing proto, aby převzal za refinemnt vlastnictví a zodpovědnost a cross-funcitional aby měl potřebné znalosti a skily.

Role Procuct Ownera tedy není jako zapisovatel, ale spočívá spíše ve výběru vhodných účastníků a facilitaci společné spolupráce než psaní samotných storek. Product Owner Je často facilitátorem spolupráce, dává konverzaci směr a smysl. Product Owner dle potřeby může vždy požádat o facilitaci ScrumMastera, ale umění facilitace dělá refinement významně snažší.

Scrum Eventy: Sprint Review

Sprint Review je klíčovým prvkem Scrumu. Probíhá na konci každého Sprintu, aby Scrum tým zjistil, jestli jde správným směrem. Nutnou podmínkou úspěchu je dodávat hodnotu, ne jen nahodilé technické tásky.

Cíl: Získat zpětnou vazbu od zákazníků, případně interních stakeholderů.

Délka: Podle počtu týmů a zákazníků bude Sprint Review trvat něco mezi 15 min a dvěmi hodinami (pro produkty dodávané více týmy).

Jak: Hlavní je si uvědomit, že cílem Sprint Review není akceptace, ale zpětná vazba od zákazníků.

  • Sprint Review není prezentace pro Product Ownera, ten je součástí Scrum týmu a na Sprint Review společně s Developery ukazují hodnotu zákazníkům.
  • Členové týmu prezentují zákazníkům hodnotu, kterou dodali, nikoliv technické řešení. Zákazníci dávají týmu zpětnou vazbu.
  • Na zpětnou vazbu není třeba nijak reagovat, jen ji pochopit. Co s danou funkcionalitou uděláme je součástí Backlog Refinementu.
  • Je vhodné, aby Product Owner neprezentoval, ale byl dobrým posluchačem a zaměřil se na získání zpětné vazby.
  • Sprint Review není o prezentaci, ale o zpětné vazbě. Často tedy místo ukazování funkcionality necháte zákazníky produkt používat a díváte se, jak s produktem pracují.
  • Na Sprint Review musíte pozvat ty stakeholdery a zákazníky kteří vám na danou funkcionalitu mohou dát relevantní zpětnou vazbu.

Scrum Eventy: Daily Scrum

Daily Scrum je nejkratší Scrum event který máme. Funguje jako zpětná vazba na spolupráci v týmu a probíhá každý den. Často se mu říká Standup nebo Daily. Aby fungoval musíte mít tým co má společný cíl, ne jen skupinu jednotlivců, co si rozdá úlohy a pak na nich samostatně pracuje.

Cíl: Cílem Daily Scrumu je podívat se, jak jsme pokročili vzhledem ke Sprint Goalu.

Délka: Jestliže vám Daily Scrum pravidelně trvá víc než 5 min, pravděpodobně tam řešíte věci, které na Daily Scrum nepatří.

Jak: Daily Scrum je reflexí týmu na self-management. I když jde vše dobře, je dobré se čas od času zastavit a podívat se, jestli vše ještě stihneme podle plánu anebo se musíme zorganizovat jinak.

  • Daily Scrum by měl být každý den ve stejný čas. Tedy nikde není řečeno, že by měl být ráno.
  • Sprint Goal není status jednotlivce a ani by neměl sklouznout k detailním konverzacím o řešení.
  • S problémy by členové týmu neměli čekat až na Daily Scrum, ale měli by je řešit v průběhu Sprintu.
  • Daily Scrum by neměl být jedinou příležitostí kdy se tým vidí. Scrum tým musí aktivně spolupracovat v průběhu celého Sprintu.
  • Daily Scrum je dobrou příležitostí se na chvíli zastavit a přeorganizovat, jak spolupracujeme.
  • Daily Scrum je pro Developery, nikoliv pro ScrumMastera nebo Product Ownera.
  • Jednotlivé položky Sprint Backlogu nevlastní jednotlivci, ale vždy celý tým.
  • V průběhu Sprintu je vhodné minimalizovat work in progress, tedy jako tým pracovat jen na jedné položce Sprint Backlogu v jeden čas, a dokončovat je tak postupně (Swarming). Tým pak má větší focus, pocit vlastnictví, a také zodpovědnost za dokončení.
  • Je doporučené nejen v rámci týmu spolupracovat na jedné položce backlogu ale i na jednotlivých táskách (Pairing, Mobbing).
  • Daily Scrum je nejen o reflexi ale i pomáhání si navzájem. Jednotlivé tásky nikomu nepatří, a tedy se často přesouvají mezi jednotlivými členy, aby tým optimalizoval práci, která je potřeba dokončit.

Scrum Eventy: Sprint Planning

Na začátku každého Sprintu tým říká, co si myslí že dokončí, tedy vybírá Sprint Backlog. Je to taková předpověď toho, co asi budou dělat, tedy je možné ji kdykoliv v průběhu Sprintu změnit. Tým se ale zavazuje, že udělá maximum pro dosažení cíle Sprintu, který se naopak v průběhu Sprintu nemění.

Cíl: Na Sprint Planning přichází Product Owner se Sprint Goalem na základě kterého potom členové týmu (Developers) vybírají Sprint Backlog a domlouvají se, jak budou jako tým spolupracovat.

Délka: Když tým rozumí Product Backlogu, business hodnotě jednotlivých položek backlogu a prioritám je Sprint Planning je poměrně jednoduchý a netrvá déle než dvacet minut. Když ovšem tým dělá Backlog Refinement až na planningu, takový Sprint Planning trvá klidně i několik dní.

Jak na to: Prerequisitou Sprint Planningu je dobré porozumění Backlogu. Prioritní položky Backlogu by měly být připravené v takové kvalitě, aby tým rozuměl dané potřebě zákazníka a věděl, jak jí bude řešit.

  • Sprint Planning je dobré vizualizovat například na Scrum Boardu, aby všichni členové týmu viděli, co plánují dělat.
  • Začínající týmy si většinou na planningu rozpadnou vybrané položky Backlogu na konkrétní tásky aby každý člen týmu rozuměl konkrétním činnostem a lépe se jim plánovalo, jak na dané položce backlogu budou spolupracovat.
  • Sprint Goal se během Sprintu nemění, položky Sprint Backlogu a tásky se mohou měnit kdykoliv existuje lepší cesta, jak maximalizovat hodnotu vzhledem ke Sprint Goalu.
  • Sprint Goal je pro Sprint jenom jeden, aby určoval směr, položek Sprint Backlogu může být více. Obvykle týmy plánují 3-5 položek backlogu na Sprint, kde ta největší by měla být týmem dokončitelná maximálně za půl Sprintu.
  • Sprint Goal je řízený potřebou zákazníka, Sprint Backlog naopak definuje, co můžeme udělat my abychom potřebu zákazníka naplnili. Tásky potom reprezentují konkrétní činnosti například business analýzu, změnu backendu, frontendu, testování apod.

Scrum Eventy: Sprint

Sprint je největší event, který ve Scrumu máme. Je to takový kontejner na všechno ostatní. Mezi jednotlivými Sprinty není žádná mezera, když jeden skončí, další začíná.

Cíl: Cílem Sprintu je dodat co nejvíce business hodnoty zákazníkovi. Tato hodnota je definovaná Sprint Goalem.

Délka: Nejčastější délka Sprintu je 2 týdny, ale v dnešní době týmy často přechází na týdenní Sprinty, aby byly flexibilnější. Obecně platí, že čím kratší, tím lepší. Cokoli delší než 2 týdny se v současné době nepovažuje za dostatečně adaptivní, nebo chcete-li agilní. Sprint je fixní časový úsek, tedy jeho délka by se neměla měnit. Pravidelnost totiž přináší předvídatelnost. Všichni si zvyknou, tým i zákazníci.

Jak na to: Scrum nedefinuje kdy má Sprint začínat, ale ukazuje se, že začínat v pondělí a končit v pátek není moc praktické. Proto týmy začátek obvykle posouvají, aby běžel například od středy do úterý.

  • Business hodnota je ve Sprintu definovaná takzvaným Sprint Goalem, tedy cílem Sprintu. Cíl Sprintu se v průběhu Sprintu nemění a určuje tak pro tým směr, kterým se daný Sprint mají ubírat. Vybrané položky Sprint Backlogu se naopak v rámci Sprintu můžou změnit, kdykoliv existuje lepší cesta jak maximalizovat hodnotu vzhledem ke Sprint Goalu.
  • Sprint Goal se v rámci Sprintu nemění. Když ale Sprint Goal přestane být relevantní, může Product Owner Sprint zrušit. V takovém případě se všechna práce vrátí na začátek a naplánuje se nový Sprint. Je to poměrně nepříjemná a drahá situace, takže se to v praxi děje poměrně výjimečně například při akvizici nebo zásadní změně na trhu.
  • Sprint Goal definuje směr, kterým v rámci Sprintu směřujeme. Product Owner může definovat i produktové cíle (Product Goals) ve formě businessových KPIs nebo OKRs, které by naopak měly být konkrétní a dlouhodobé. Většinou trvá několik Sprintů, než se týmu podaří jich dosáhnout.
  • Sprint Goal definuje směr, ne co konkrétně se má dokončit.

Každý Sprint má obvykle jiný Sprint Goal.

Sprint Goal – příklad

Jedna z častých otázek je, jak má správně vypadat Sprint Goal. Pojďme se ale nejdřív podívat, co to je. Sprint Goal dává Sprintu smysl. Definuje, čeho chceme dosáhnout. Dává dostatečně silný důvod jeho existence. Proč by měl Product Owner do Sprintu investovat (čas i peníze). Vyplatí se to? Sprint Goal je nedílnou součástí prioritizace Backlogu. Sprint totiž není o dodání jednotlivých položek Backlogu, ale o dosáhnutí cíle Sprintu, tedy Sprint Goalu.

Sprint GoalJak by mohl takový Sprint Goal vypadat? Když o něm slyšíte úplně poprvé, můžete začít třeba Sprint Goalem, který je implementací větší položky Backlogu. Jako je třeba:

Ve Sprint Backlogu potom budou různé položky Backlogu, které tvoří jednotlivé části Dashboardu.

Sprint Goal: “Dashboard“ 

Příklad PBIs: “Tabulka s příjmy a náklady, graf cash-flow, semafor zdravosti financí, seznam nezaplacených faktur.“

Když budete chtít v pochopení Sprint Goalu pokračovat, tak o trochu lepším cílem sprintu je podívat se na to z pohledu business hodnoty a zákazníka a identifikovat tak potřebu, například:

Jednotlivými položkami Backlogu, které pak tým následně vybere z Backlogu budou nejen položky tvořící Dashboard, ale například notifikace, které užitečnosti přehledu o financích můžou přispět i více než samotný dashboard.

Spring Goal: “Zvýšit přehled o financích“

Příklad PBIs: “Tabulka s příjmy a náklady, graf cash-flow, semafor zdravosti financí, notifikace o překročených limitech, notifikace o fakturách po splatnosti“.

Na závěr už zbývá jen přidat příklad, jak by takový Sprint Goal nikdy vypadat neměl. “Dokončit PBI1, PBI2, PBI4 a PBI6 podle definice“. Takový Sprint Goal je příkladem tradičního mindsetu a naprostého nepochopení toho o čem Scrum je. Tedy zaměňuje Sprint Goal za konkrétní specifikaci, a Backlog za ToDo list. Ale ani jedno není Scrum. Scrum je takzvaně ‘purpose driven‘. Tedy řízený nějakým vyšším smyslem, něčím, co přináší hodnotu pro zákazníka. Něčím, do čeho byste byli ochotni investovat svoje peníze, abyste další Sprint zaplatili. A pak další, a další. Něco, čemu věříte natolik, že byste do toho šli.

Nejčastější nepochopení Scrumu

Scrum je velmi jednoduchý framework. Bohužel ale není vůbec snadný aplikovat. Je to velká změna myšlení, přístupu, hodnot. Když se půjdete do běžné firmy podívat, tohle asi budou nejčastější nedorozumění, a nepochopení, na které narazíte:

Scrum

Daily Scrum jako status meeting

Daily Scrum alias Standup meeting je tak triviální věc, že by jeden řekl že se snad ani nedá zkazit. Chyba lávky. 80% firem ho bere jako status meeting, kde každý jednotlivec referuje (managerovi, ScrumMasterovi, nebo ostatním členům týmu) co dělal. A kosmetické změny ScrumGuidu, které se snaží vysvětlit, že je to celé o synchronizaci týmu, jejich diskusi, jak dosáhnou cíle Sprintu (Sprint Goal), zůstávají bez povšimnutí. Kde jinde bychom ty líné vývojáře kontrolovali a řídili, vždyť jinak nebudou nic dělat.

“Cílem Daily Scrumu je synchronizace členů týmu a jejich dohoda, jak budou dále pracovat na dosáhnutí cíle Sprintu, tedy Sprint Goalu.“

Sprint Backlog se nesmí měnit, je klíčový

Když už jsem zmínila Sprint Goal, pojďme u něj zůstat. Většina firem žádné Sprint Goaly nepoužívá. Vystačí si se Sprint Backlogem, který navíc mylně vnímá jako neměnnou specifikaci, která do detailu popisuje, co přesně má tým (rozuměj ‘coding monkeys‘) naimplementovat. Sprint Backlog je ale jen rámcovou dohodou, jak chceme dosáhnout cíle Sprintu. Klíčovým artefaktem je Sprint Goal, který definuje, čeho z pohledu business value chceme dosáhnout. Ten by se měnit neměl, protože to je to do čeho v rámci Sprintu investujete. Sprint Backlog se naopak v závislosti na situaci a dohodě týmu klidně měnit může. V podstatě s tím, jak se ve Scrumu začal Sprint Goal více používat, přestal být Sprint Backlog téměř potřeba, natož aby byl neměnný.

“Sprint Goal definuje smysl Sprintu, čeho chceme z pohledu business value dosáhnout. Sprint Backlog nám pouze pomáhá udělat dohodu ‘jak’ toho chceme dosáhnout. “

Sprint Review je o akceptaci

A do třetice všeho dobrého, nebo spíš zlého :), takové běžné Sprint Review alias Demo velmi často skončí jako prezentace technických scénářů Product Ownerovi. Proč prezentujeme něco někomu, kdo měl být celou dobu přitom, je mi záhadou. Někde prezentujeme Product Ownerovi proto, že nikoho jiného technické scénáře nezajímají, jinde protože se bojíme členy týmu komukoli ukázat, aby neudělali ostudu, jinde ani Product Owner nechodí a děláme to jen protože Scrum. Sprint Review je klíčovým prvkem Scrumu, protože právě tady získáváme zpětnou vazbu na doručený Sprint Goal, tedy funkční inkrement produktu, nebo jinak řečeno dodanou business hodnotu. Jdeme správným směrem? Je tohle opravdu business hodnota? Dosáhli jsme očekávaného impactu? To jsou otázky, které je dobré si v rámci Sprint Review položit.

“Cílem Sprint Review je získat zpětnou vazbu od zákazníků, stakeholderů, uživatelů abyste se na jejím základě mohli adaptovat. Je to klíčovým prvkem a by vám fungoval proncip Inspect and Adapt.“

 

Jestli jste se ve výše zmíněných příkladech nepoznali, dobrá zpráva. Asi jste se už vymanili z područí ‘Technického Scrumu’, nebo ’Dark Scrumu’ a jste o krok blíže změně mindsetu. Jen tak dál 🙂