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.

Přijďte na konferenci Agile Prague

Jako každý rok, chystáme v září konferenci Agile Prague. Agile Prague je každoročně největší událostí Agilního světa a stejně jako poslední roky má bohatý program. Takže na co se můžete těšit? Každý den začínáme dvěma keynotes, dále pak program kombinuje krátké 30 min talky které jdou vždy do hloubko konkrétního tématu, praktické odpolední workshopy a case-studies z agilních organizací.

Jako již tradičně poledne není jen čas oběda, ale i možnost zapojit se do openspace, kde program vzniká na místě a kdokoli z vás může nabídnout jakékoli téma o které se chce podělit nebo se o něm něco dozvědět. Věnovat se budeme velkým transformacím, leadershipu, modernímu managementu, kultuře týmů, produktům a scalingu, agilitě na úrovni organizace. Nechte se inspirovat.

Po oba dva dny zároveň běží Coaches Clinic, tedy místo, kde vám zkušení koučové poradí s čímkoli budete potřebovat.

Letos se můžete těšit na skvělé řečníky, například Mirko Kleinera, leadera v oblasti Lean-Agile Procurement, Romana Pichlera, předního odborníka na produktový management, a Pera Beininga, jediného autorizovaného školitele FaST v Evropě. A tak bych mohla pokračovat.

Ostatně posuďte sami a podívejte se na program konference.

Jako obvykle je konference v okolních dnech doplněna několika 2 denními  workshopy:

  • ICAgile Certified Professional in Agile Coaching s Johnem Barrattem 18.–19. září 2024,
  • Business Resilience s Angel Diaz Maroto 18.–19. září 2024,
  • Org Topologies™ Practitioner s Alexey Krivitskym a Rolandem Flemmem 12.–13. září 2024.

Září je veskrze agilní měsíc. Hned po AgilePrague která se koná 16.-17. září je 18. září přes ulici konference Women In Agile. A jako rozehřátí si můžete 9.-10. září ještě před Agile Prague zajet do Stockholmu na Regional Scrum Gathering.

Myslím, že se je na co těšit. Doufám, že se tam v září potkáme.  Registrujte se včas, míváme vyprodáno. 

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.

Jak na Scrum Eventy

Když to řeknu jednou větou, Scrum je iterativní a inkrementální styl práce, zaměřený na týmovou spolupráci a maximalizaci business hodnoty. Nic složitého. To ale neznamená že ho organizace hned napoprvé implementují správně. Scrum totiž mění poměrně hodně zažitých věcí. Tentokrát bych se chtěla podívat na eventy. A jen tak mimochodem, neříkáme jim ani “ceremonie“ (které týmy dělají jen tak naoko, protože Scrum říká že se to musí), ani “meetingy“ které někdo pro tým musí zorganizovat. Event je bližší slovu “happening“. Tedy něčemu, co se děje skoro by se dalo říct samo od sebe, protože všichni chtějí, aby se to dělo. Nikde se nic nemusí plánovat, všichni vědí, kde a kdy event je a účastní se, protože jim to připadá užitečné a smysluplné.

Eventů je ve Scrumu pět a se dějí pravidelně. Mají sice definovanou maximální délku, ale je dobré vědět že pro kratší Sprinty eventy trvají významně kratší dobu. Důležitá je hlavně pravidelnost. Tím, že se dějí pravidelně, pomáhají týmu ale i zákazníkům si na iterativní styl práce zvyknout a lépe plánovat, připravovat se, a vědět co se děje.

Asi nejčastější problém je, že se týmy snaží aplikovat Scrum na jednotlivce místo na tým a že v Product Backlogu mají nahodilé tásky, nikoliv položky backlogu definující business hodnotu. V takovém prostředí většina eventů nefunguje, protože jsou založené na týmové spolupráci a dodávání hodnoty. Ze Sprint Planningu se stane alokace práce pro jednotlivce, z Daily Scrumu se stává micromanagerský otravný meeting, Sprint Review ukazujeme jen tak sami sobě, protože drobné činnosti vlastně nikoho nezajímají, a na Retrospektivě si postěžujeme, jak nám ten Scrum nefunguje. Nic, co byste chtěli zažít. A nemá ani moc cenu nutit jednotlivce Scrum eventy vykonávat, dokud místo skupiny jednotlivců nemáte tým a dokud v Product Backlogu nemáte opravdové položky backlogu zaměřené na hodnotu. V momentě, kdy se tyto dvě věci spraví, dějí se eventy vlastně samy od sebe, protože týmu pomáhají se lépe zorganizovat a dosahovat větší hodnoty pro zákazníka.

Když budete mít tým a relevantní Product Backlog, zbývá už jen vysvětlit k čemu jednotlivé Scrum eventy jsou a jak by měly vypadat. A na to se podíváme v následujících příspěvcích: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Retrospektiva.

Retrospektiva #10 – Bingo!

Na závěr svého seriálu o různých formátech retrospektivy přidám formát, který je nejvíce kreativní, až by se dalo říct bláznivý. Hrajete rádi Bingo? Tak to je dobrá zpráva, protože si ho můžete s vaším týmem zahrát na další retrospektivě. Takže jak taková retrospektiva probíhá. Tým společně brainstormuje události, které se staly v rámci Sprintu ať už na lístečky nebo na online board. Když brainstormujete na lístečky, každý si musí napsat stejnou sadu událostí. Každý si sestaví vlastní Bingo! board – lístečky jsou stejné, ale pozici jednotlivých lístečků každý určuje sám. Jeden člen týmu lístečky zamíchá a čte je jeden po druhým. Ostatní si označují, co už zaznělo a kdo má první řádek, sloupec nebo diagonálu zavolá “Bingo!“ a vysvětlí ostatním, jak on vnímal dané události. Pak se zase lístečky zamíchají, čte další člověk.

Výhody:

  • Je to velice hravá forma retrospektivy, posiluje pozitivitu v týmu.
  • Ukazuje různé perspektivy a zdůrazňuje, jak různí lidé vnímali dané události různě.

Nevýhody:

  • Chvíli trvá, než vymyslíte board s událostmi a všichni si napíšou stejné kartičky.
  • Lze hrát i s lístečky, ale v online světě je to daleko snazší.

Tip:

  • Online nástroje umožňují jistou automatizaci, takže stačí aby si kartičky každý zkopíroval třeba v Miru nebo Muralu.
  • Použijte Bingo! generátor a zahrajte si hru online. Např. https://bingobaker.com

Retrospektiva - bingo

Retrospektiva #9 – Cesta na pláž

Jedna z kreativnějších forem retrospektivy je na motivy dětské hry. Má samozřejmě mnoho forem, jako příklad uvedu cestu na pláž, která v tomto případě představuje metaforu Sprintu. Jak taková retrospektiva probíhá? Jednotliví členové si představí Sprint jako cestu na pláž a začnou ji vyprávět. “Cestou na pláž přišla bouřka.“ řekne první. A další člen týmu pokračuje: “Cestou na pláž přišla bouřka  a my jsme se ztratili a nevěděli jsme kudy dál.“ A další člen týmu zopakuje, co řekli ti před ním a přidá další událost: “Cestou na pláž přišla bouřka, my jsme se ztratili a nevěděli jsme kudy dál a všude bylo mokro a bláto…“ a tak dál. Každá událost v cestě na pláž je metaforou toho, co se stalo ve Sprintu.  

Výhody:

  • Občas tým potřebuje změnu a tahle retrospektiva je legrace. Každý musí hádat, co který kus cesty na pláž znamenal v realitě, a také být schopen si celou cestu zapamatovat.

Nevýhody:

  • Není to retrospektiva pro začínající nebo dysfunkční tým, ale dobře fungujícímu týmu může rozšířit perspektivu a pomoci dívat se na věci jinak.

Tip:

Nechte tým vymyslet i to co bude metaforou pro Sprint. Cesta na pláž je jen jednou z možností.

Retrospektiva - cesta na plaz

Retrospektiva #8 – Uznání

Pozitivita je důležitá. Dobře fungující týmy mají poměr pozitivních vs. negativních událostí v průměru 5:1. Ne vždy musí být retrospektiva o tom, co se nám nedaří. Občas je dobré se podívat primárně na to, co je výborné a chtěli bychom to ocenit. V této retrospektivě jednotliví členové ocení přínos jiných členů týmu. Je to o poděkování a pochvale ostatních.

Výhody:

  • V týmu vzroste energie a všichni si uvědomí kdo má jaký přínos pro tým.
  • Je to takový teambuilding. U každého vzroste dobrý pocit z toho, že si ostatní cení jeho práce.

Nevýhody:

  • Občas není snadné začít hledat jen ty pozitivní věci.

Tip:

Někdy necháte členům týmu si vybrat koho ocení, jindy můžete připravit lístečky se jmény a nechat členy týmu vylosovat koho mají ocenit. Je to tak zábavnější a na každého se dostane.

Retrospektiva - uznani