Sprint Review

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

Sprint Review je jednoduchý meeting, který ale většina firem nepochopila. Jak se jako Agilní Coach chodím dívat na různé Scrum týmy, nejčastější chybou je, že Sprint Review považují za Sprint nebo Release status. A tak se tenhle zajímavý meeting stává pro spoustu firem noční můrou. Rozhoduje se zde, jestli byl tým úspěšný, kolik slíbil a kolik dodal. Ale to je zcela mimo definici toho, co by se tu mělo dít.

Jestli jste si oddychli, že takhle to u vás není, mám pro vás druhou nejčastější chybu, a to že na Sprint Review prezentuje tým Product Ownerovi co dokončil. Je to asi o chlup lepší, ale pořád úplně vedle. Product Owner je součást Scrum týmu a tedy dokončenou funkcionalitu akceptuje hned jak je hotová, tedy v průběhu Sprintu. Tedy na review už ji dávno viděl a dal na ni zpětnou vazbu.

Další chybou v pořadí je, že neprezentuje tým, ale Product Owner. Tým je přeci banda introvertů co nerozumí businessu, tak jak by mohli předstoupit před zákazníka, že? No alespoň oproti předchozím variantám něco ukazujete zákazníkovi a dostáváte zpětnou vazbu. O tu jde totiž na Sprint Review především.

Ideálním stavem je, že tým prezentuje zákazníkovi, co dokončil. A na oplátku získá zpětnou vazbu od zákazníka. Není to žádná technická prezentace jak je to naimplementované, ani přehlídka jednotlivých User Stories, ale souhrnná prezentace toho, jak jsme doručili za daný Sprint hodnotu definovanou cílem Sprintu. Jak již jsem naznačila, prezentuje tým. Kdo konkrétně? No to je snadné, kdokoli. Z výborně fungujících týmů je schopný hodnotu Sprintu prezentovat kdokoli. Jak to vypadá v praxi? Přijdete na Sprint Review, tým vylosuje jednoho člena a ten prezentuje. Že to není možné? Když tým spolupracuje v rámci Sprintu vždy na jedné UserStory (viz praktika “One UserStory at a time“), není to problém. Je důležité si uvědomit, že neprezentujeme detailní řešení, ale Sprint Goal, tedy hodnotu dodanou v daném Sprintu.

Žádný meeting ve Scrumu není klasický status meeting

Víte, že žádný meeting ve Scrumu není klasickým status meetingem?

Daily Scrum (Standup meeting)

Začněme Standupem, kde antipaternem je, že jednotliví členové týmu reportují, co všechno dělali a co dělat budou. Asi aby je ScrumMaster nebo ostatní členové mohli kontrolovat.

Standup je tu ale proto, aby se tým a jeho členové každý den rychle zastavili a řekli si, jestli jdou správným směrem a jestli ještě stále věří tomu, že zvládnou dodat Sprint Goal. Proto nekontrolujeme, čím trávili čas, ale soustřeďujeme se na to, co je hotovo, a jak budou spolupracovat na tom, co mají teprve dokončit.

Sprint Review

Dalším v řadě je Sprint Review, kde antipatern je prezentovat, které konkrétní UserStory se dokončily a které ne. Spousta týmů status dotáhla do dokonalosti a dokonce ukazuje prezentaci a jakési grafy a vyhodnocuje úspěch a neúspěch Sprintu.

Sprint Review je tu ale proto, abyste ukázali Potentional Shipable Product Increment – tedy to, co tým dokončil – zákazníkovi a získali na základě toho zpětnou vazbu. Ta je potom cenným vstupem pro Backlog Refinement a pomáhá vám dodat úspěšný produkt.

Retrospektiva

Do třetice je tu Retrospektiva, kde antipaternem je začínat Retrospektivu tím že procházíte jednotlivé body z minula a hodnotíte, jak se vám povedly dokončit a jestli zabraly na daný problém.

Retrospektiva ale má být kreativním workshopem, kde se tým zamýšlí nad tím, co by chtěli změnit, co jim vyhovuje, co naopak chtějí zlepšit. Aby fungovala, musíte se na sebe umět podívat jinýma očima, z venku. A když začnete statusem, tak ten nadhled ztratíte a v další fázi pak jen zopakujete, co vám zbylo z minula. Máte-li pocit, že se věci nehýbou kupředu, určitě to na další retrospektivě zazní znovu i bez opakování. A status těch pár Action Items z minula můžete dát na tabuli a skouknout na Standupu.