Nový Scrum Guide

Minulý týden se objevila nová verze ScrumGuidu. A zdá se, že je to cesta dobrým směrem. Popis je srozumitelnější, jednodušší a obsahuje méně detailů. Tady je pár rozdílů.

Scrum Guide

#1 – Scrum Guide 2020 je jasnější

Scrum Guide 2020 je jednodušší a jasnější. Konečně je psán srozumitelným jazykem a jasně popisuje co je Scrum. A protože Scrum je jednoduchý, je příjemné vidět že Scrum Guide může být také jednoduchý. Konečně se dobře čte a konečně jsme se zbavili přílišných detailů, jakým byly tři otázky na Daily Scrumu. Po mnoha letech neporozumění, kdy týmy brali Daily Scrum jako meeting kde každý reportuje svůj status, doporučuje Scrum Guide týmům vybrat si jakoukoli formu která jim pomůže lépe spolupracovat a maximalizovat hodnotu vzhledem ke Sprint Goalu. Za mě naprosto super.

#2 – Vše je o mindsetu

Líbí se mi, že nový Scrum Guide vypichuje tři pilíře emiricismu (transparentnost, inspection, adaptation) jako důležitou součást Scrumu spolu s pěti hodnotami Scrumu – commitment, focus, otevřenost, respekt, a odvaha a že se upřednostňuje to jak se lidé chovají před procesy a praktikami.

Další dobrou věcí je připomenutí, že Scrum se hodí primárně pro řešení komplexních problémů v nepředvídatelných prostředích a že různé techniky odhadování, měření velocity a kreslení burndown grafů se sice může zdát na první pohled užitečné, ale ve Scrumu upřednostňujeme schopnost rychle se měnit na základě zpětné vazby, tedy empirický přístup.

#3 – Scrum Team Focus

Největší změnou je to, že Scrum tým netvoří “Development tým”, ScrumMaster a Product Owner, ale “Developers”, ScrumMaster, a Product Owner. Vypadá to zdánlivě jako velká změna, ale není tomu tak. V obou případech všichni spolupracovali na maximalizaci hodnoty vzhledem ke Sprint Goalu, takže se vlastně nic nemění, jen jsme se snad nadobro zbavili typického nepochopení Scrumu, kde tým dodával Product Ownerovi a bral ho jako nepřítele. Teď je explicitně řečeno, že jsou na prvním místě týmem a že na výsledné hodnotě spolupracují. Tedy žádný dodavatel – odběratel vztah, ale cross-functional tým, co táhne za jeden provaz. Jsou v tom spolu.

Jediná vada na kráse je, že ‘Developer’ je dost nešťastně zvolené jméno, protože většině lidí asociuje software developera. Lepší výraz by asi byl ‘product worker’, tedy někdo, kdo na produktu pracuje a má potřebné znalosti a zkušenosti k tomu, aby týmu pomohl dodat end-to-end hodnotu pro zákazníka. Developeři jsou stále ti, kteří každý Sprint dodávají funkční produkt, zatímco Product Owner se zaměřuje na maximalizaci hodnoty a ScrumMaster na zlepšení fungování organizace a týmů.

Nový Scrum Guide přináší také jasnější doporučení pro scaling “Když by byl Scrum tým moc velký, můžete zvážit jeho rozdělení do více cross-functional Scrum týmů, které spolupracují na jednom produktu. V takovém případě týmy sdílí Product Goal, Product Backlog, a Product Ownera.”

#4 – Product Goal, Sprint Goal, a Increment

Konečně poslední změnou je přidání cíle produktu (Product Goal), lepší vysvětlení cíle Sprintu (Sprint Goal) a zjednodušení popisu Incrementu. Změny nejsou v praxi nové ale Scrum Guid zde dost pokulhával za běžnou praxí. Nový Scrum Guide nám take dává jistou definici produktu, která je mnohem širší, než si mnoho organizací myslí: Produkt je nástrojem, který přináší hodnotu. Má jasnou hranici, známé stakeholdery, dobře definované uživatele nebo zákazníky. Produktem může být služba, fyzický produkt nebo něco abstraktnějšího.“ Product Goal je pro Scrum tým dlouhodobým cílem a vizí. Sprint Goal dává každému sprintu smysl a definuje hodnotu, na kterou se nyní zaměřujeme. Increment je funkční produkt který je kvalitně zpracován, otestován přináší hodnotu vzhledem ke Sprint Goalu. Jednoduché a jasné. Konečně také existuje mnohem lepší popis Definition of Done: „V okamžiku, kdy Product Backlog Item splňuje Definition of Done, zrodí se Increment.“

Celkově se mi nová verze Scrum Guidu opravdu líbí. Na tom, co jsem učila a používala, se nic moc nemění, přináší ale jasnější a čistší definici Scrumu, tak jak ho znám. A to je určitě dobře.

Proč Scrum ve firmách nefunguje

Čas od času přijde někdo a říká, že Scrum nefunguje a že oni jsou agilní a to že je lepší. Dovolím si oponovat. Ne proto, že by někdo nemohl být agilní bez Scrumu, ale proto, že teorie a realita jsou obvykle dost daleko od sebe a Scrum je zatím stále nejjednodušší a nejúspěšnější cesta, jak se stát agilními. Nemusíte souhlasit, ani pokračovat ve čtení. Ani jedno není povinné. Ale jestli vás zajímá můj názor na to, proč Scrum v některých prostředích nefunguje, tak tady je hned několik nejčastějších důvodů. Není to o businessu, ve kterém jste, ani o velikosti. Dobrá zpráva je, že všechny jsou snadno řešitelné, jak jinak než implementaci opravdového Scrumu, nikoliv fake-Scrumu, nebo “DarkScrumu“.

#1: Neexistence týmu

Nejčastějším důvodem, proč Scrum nefunguje je, že nemáte tým. Lidi pracují každý na svých úkolech, jako jednotlivci. V takovém případě se vytrácí celá podstata Scrumu a zbudou nesmyslná pravidla a “DarkScrum“ je temně černý. Tým je podstatou kvality, motivace, schopnosti adresovat komplexní problémy a nacházet inovativní řešení. Jak se tedy liší tým od skupiny jednotlivců? Tím že spolupracuje. Je postavený na důvěře, schopnosti nebát se říct si věci do očí, k něčemu se společně zavázat, vzít za věci zodpovědnost, a mít jeden společný cíl (viz kniha Five Dysfunctions of a Team). Začít můžete tak, že tým má jeden společný Sprint Goal (businessovou vizi sprintu), která je spojuje a společně plánuje, jak by v rámci Sprintu tuto hodnotu mohli maximalizovat (forecast). Když nechcete aplikovat rovnou mob-programming a pracovat všichni najednou na jednom úkolu, jednom počítači a jedné klávesnici, dobrou praktikou pro posílení spolupráce je “one story at a time“ kde celý tým spolupracuje na různých úkolech jedné konkrétní položky backlogu alias story a teprve když ji dokončí, dá se společně na další. Tým na to nepotřebuje žádného manažera ani asistenta, organizuje se sám. Dobrá zpráva je, že na to, abyste měli skvěle fungující self-organized tým je tady ScrumMaster.

#2: Komponent týmy

Kromě toho že je to self-organized tým, musí být také cross-functional. To neznamená že každý umí všechno, ale že jako tým mají všechny potřebné znalosti a zkušenosti k tomu, aby mohli vzít libovolnou položku backlogu a tu dokončit. Sami, bez dependencí na kohokoli jiného. Klasicky smýšlející organizace se často takové bojí týmy postavit. Většinou za tím stojí strach o ztrátu moci, nebo limitující kontrakty s dodavateli a obava je změnit. Firmy proto končí s komponentně orientovanými týmy, které i při nejlepší vůli nedokážou udělat nic, co by za něco stálo a dokázalo se prezentovat zákazníkům na Sprint Review, ze kterého se stává bezduchá akceptace dílčích kousků. Nic, na co by šla získat zpětná vazba. “DarkScrum“ je více či méně tmavě šedý, v závislosti na tom jak fragmentované jsou komponenty a ošklivé dependence. Stejně jako v minulém bodě, vysvětlovat důležitost a prosazovat cross-functional tým je na ScrumMasterovi.

#3: Nejasná business hodnota

Dalším bohužel docela častým problémem je to, že nikdo není schopen definovat business hodnotu. Divili byste se, kolik organizací není schopno definovat vizi. Je to frustrující, a obvykle to končí tím, že týmy říkají „dejte nám specifikaci, my to podle ní vyrobíme“. A “DarkScrum“ je černo-černý. Ve Scrumu totiž žádná detailní specifikace neexistuje. Máme jen vizi produktu, businessově orientovaný Sprint Goal a businessové položky backlogu, které nejsou zaměřené na implementaci, ale na business value. Implementace je velice flexibilní a je na týmu ji v rámci Sprintu vymyslet tak, aby se hodnota dodaná v daném Sprintu maximalizovala. To je ostatně rolí Product Ownera, který musí mít autoritu rozhodnout o prioritách, a být schopen upřednostnit tu část Backlogu, která přináší nejvyšší hodnotu.

#4: Proč bychom se měli měnit?

Asi posledním z důvodů, proč vám Scrum nefunguje, ale kterým byste asi měli začít, je uvědomit si proč byste se měli měnit. Co se stane, když se nezměníte. Že nebudete agilní? No to asi nikomu nevadí. Agile není váš cíl, ale jen cesta, jak se k němu dostat. A Scrum není jediná možnost jak se agilními stát. Jen podle mne ta nejefektivnější a nejúspěšnější. Jak říká guru change managementu John Kotter, když chcete, aby změna byla úspěšná, musíte vytvořit pocit nutnosti, neodkladnosti, urgentnosti.  Lidi ani organizace se nemění, protože někdo vymyslel nový proces. Mění se, protože musí. Není to o tom, jestli se vám současný proces líbí nebo ne, pomáhala jsem změnit se firmám, které milovaly waterfall. Ale jediné firmě, které pomoct neumím je té, co nechce. Bez pocitu, že změnu nutně potřebují se žádná změna nestane. Je to moc práce. A změna kultury a mindsetu, kterou Agile a Scrum přináší je ta nejtěžší, kterou znám. Jestli se tedy chcete už v začátku vyvarovat stupňům šedi “DarkScrumu“, začněte s jasným důvodem, proč je změna nutná. Celá implementace bude pak výrazně méně náchylná k “tmavnutí“. Je to jako posílení imunity, jako vitamíny.

#5: Částečný Scrum

Jestliže předchozí odstavce jsou dané nepochopením, tohle je čistý alibizmus. Není to důvod proč Scrum nefunguje. Není to totiž Scrum. V angličtině se tomu říká Scrum-but. Tedy “my máme Scrum, ale neděláme retrospektivy. My máme Scrum, ale nemáme ScrumMastera, my máme Scrum, ale nemáme cross-functional týmy“. Nikdo vás nenutí Scrum nasadit, ale když už se do toho pustíte, tak buď pořádně, anebo vůbec. To, že nějaký paskvil nazvete Scrumem nepomůže ani vám, ani ostatním. Ba právě naopak. Ostatní odradí od toho to zkusit pořádně a vám přinese jen tu nejčernější verzi “DarkScrumu“.

Jak hledat Product Ownera

Dobrý Product Owner by měl mít znalost businessu, autoritu a čas.

Product OwnerZnalost businessu je něco víc než znalost produktu a jeho funkcí. Na to často stačí dobře fungující development tým. Je to i pochopení celého segmentu zákazníků, jak se business chová, co na trhu chybí a po čem je poptávka.

Autorita je potřeba, aby se Product Owner dokázal dobře rozhodnout, co udělat teď a co později, nebo nikdy, tedy prioritizovat na základě business hodnoty. Product Owner musí umět říct “ne“.

Čas je nutný nejen vzhledem k zákazníkům a businessu, ale i development týmu. Dobrý Product Owner je součástí týmu a spolu s development týmem a zákazníkem (interní stakeholdeři, uživatelé, … ) spolupracuje na porozumění backlogu. Product Owner není tichá pošta mezi týmem a zákazníky, ani ten kdo píše všechny položky backlogu/User Story. To se vše děje společně na Backlog Refinementu. Product Owner tedy musí být dobrý v komunikaci, umět vyjednávat, a facilitovat větší workshopy (Refinement) a umět věci jasně vysvětlit a komunikovat.

Znalosti by měl mít alespoň na úrovni na úrovni certifikací CSPO – Certified Scrum Product Owner (případně CSM – Certified ScrumMaster jako doplněk pro hlubší pochopení Scrumu.

Zkušenost ze Scrum prostředí: Dobrý Product Owner by měl zažít pravý Scrum na úrovni celého produktu, zkušenosti ověřené certifikací A-CSPO – Advanced Certified Scrum Product Owner, nebo v lepším případě CSP-PO – Certified Scrum Professional – Product Owner).

Alespoň základy (a plánuje se rozvíjet v daných oblastech): Vyjednávání, komunikace, facilitace, schopnost naslouchat, leadership skills.

Dobrý Product Owner by měl být schopen efektivně spolupracovat v rámci týmu.

Když se nad tím zamyslíte, dobrý Product Owner se daleko snáz hledá interně, než najímá externě, ostatně je to někdo, kdo má na starosti celkový úspěch businessu, takže je lepší vzít někoho koho znáte a víte, že ve vašem businessu dobře orientuje. Product Ownerů navíc nepotřebujete tolik, na jeden produkt (i ten větší) stačí jeden Product Owner. Ostatně není na to sám, pomáhají mu v rámci Backlog Refinementu development týmy.

Jeden produkt, jeden Product Owner

Jeden z nejčastějších dotazů je, proč má být ve Scrumu jeden Product Owner na celý produkt, proč na každý systém není jiný Product Owner (tedy proč nemáme komisi Product Ownerů) popřípadě proč každý tým nemá svého Product Ownera (team PO, proxy PO). A když už tedy máme jednoho PO jak to může všechno stihnout.

Začneme od začátku. Jednoho PO máme, protože máme jeden produkt. A ten potřebuje pro svůj úspěch jasný směr, jasnou vizi na jejímž základě má každý produkt jeden prioritizovaný backlog na základě business value. Komise je těžkopádná, nemá na věci jednotný pohled a jen těžko se domluví. Obvykle končí doporučením, že tohle všechno musíte udělat jako prioritu jedna. Tedy máte skupinu stakeholderů (nebo zákazníků, jak je v agilním světě nazýváme), ale žádného Product Ownera. Konsekvence je nekvalitní backlog, nejasné priority a zákulisní boje. Týmový /Proxy Product Owner je zase nešvar, který jsme zdědili z klasického vnímání development týmu jako tzv. ‘Coding monkeys’ tedy codérů, kteří tupě nakódují co někdo jiný naspecifikoval bez toho, aniž by jakkoli přemýšleli, jestli daná implementace vede k cíli. V lepším případě component týmů (které mají na starosti jen určitou část systému) a nedokážou tak žádnou hodnotu dodat. Když týmy nedodávají end-to-end hodnotu, nemůžou získat relevantní zpětnou vazbu a celé Sprint Review je zbytečné. Component týmy nemají dostatečný přehled o celkovém businessu, požadavkům ve formě user story nerozumí, a tak požadují, aby jim někdo napsal detailní akceptační kriteria /specifikaci, aby věděli co se má v dané komponentě udělat. A protože businessově orientovaný PO věcem technicky nerozumí a ani na to nemá čas, instalují asistenta, který jim to připravuje. A jsme zpět ve waterfallu. Nejdřív se udělá specifikace, pak podle ní vyvíjí produkt. Takže tudy cesta také nevede. Tedy jestli chcete zůstat v tradičním světě, proč ne. Rozhodnutí je na vás. Jestli ale chcete aplikovat Scrum tak jak byl zamýšlený, a hlavně tak aby fungoval, odpověď je snadná.

Backlog Refinement is about collaborationJeden produkt (a o tom jak se takový produkt definuje už jsem tu psala) má jednu vizi, jeden backlog, a tedy i jednoho PO. Na produktu může pracovat několik cross-functional týmů, které každý za sebe dokážou dodat end-to-end hodnotu, tedy plně funkční produkt. Aby to jeden PO zvládal, nepracuje sám, ale v rámci backlog refinementu mu pomáhají již zmíněné týmy, které společně s PO a zákazníky backlog připravují a starají se o to, že všichni rozumí prioritám i jednotlivým položkám backlogu. Asi nejčastější chybou, která k výše zmíněnému ‘fake PO’ vede je představa, že Product Owner píše položky backlogu, které když jsou ready předává týmu a ten je podle jeho požadavků naimplemetuje. Tak to ale ve Scrumu být nemá a nikdy být nemělo. Refinement je týmová práce a podílí se na ní všichni. Zákazníci, stakeholdeři, uživatelé, cross-functional týmy, a Product Owner a položky backlogu definují společně.

Když to celé zjednoduším. Scrum je o týmové spolupráci (nejen v rámci Scrum týmu ale i se zákazníky), jasných prioritách (proto máme jednu hlavu, jednoho Product Ownera) a dodávání hodnoty (cross-functional týmy).

ScrumMaster by měl pomáhat Product Ownerovi

Pryč je doba, kdy ScrumMaster byl v podstatě jen členem Development týmu, a Product Owner nepřítel, kterého bylo třeba vytlačit pryč. Naštěstí. Jak ScrumMasteři rostou a jejich týmy se stávají více a více self-organized, začínají mít více času věnovat se druhé úrovni #ScrumMasterWay konceptu. A jednou z částí je i pomáhat Product Ownerovi. Z čeho taková pomoc sestává? Tak za prvé dát pozor na to, že existuje jasná vize, a je pochopená jak development týmem, tak i stakeholder a zákazníky. Často samotná existence vize je problém, který trvá několik měsíců. Schopnost ji komunikovat a nadchnout pro ni, už nebývá tak složité. Zrovna tak jako Backlog Refinement, který se bez vize stává noční můrou, funguje v případě dobře definované vize v podstatě sám. Je to v podstatě o pár praktikách. Kdy píšeme položky Backlogu jako UserStory, kdy je lepší aplikovat Story Mapping, nebo Impact Mapping? Dobrý ScrumMaster by měl být schopen takové praktiky doporučit a také naučit, a následně takový workshop se stakeholdery být schopný i v případě potřeby facilitovat. A můžeme pokračovat, vědět, kdy prioritizujeme seřazením, kdy používáme některé z innovative games, kdy KANO, kdy relativní váhy. Metod je mnoho. A můžete se je učit donekonečna. Pořád budete nacházet další a další. A můžete říct, že to je přeci na Product Ownerovi, aby si našel to, co potřebuje. Ale když neví, obrátí se na experta a tím by měl být ScrumMaster, který se neustále vzdělává a je neustále o krok před týmem, Product Ownerem a organizací. ScrumMaster by měl být někým, kdo umí vždy poradit a nasměrovat. Kdo ví jak na to. Kdo je dobrým facilitátorem, aby dané metody dokázal poprvé týmu předvést a provést je jimi. Když to budete dělat dobře, Product Owneři si tyto praktiky brzy osvojí a budou si je facilitovat sami. A vám zbude více času na třetí úroveň #ScrumMasterWay konceptu – tedy celý systém. A o to vlastně jde.

Pět nejčastějších chyb Agilní a Scrum transformace

ScrumMaster řeší překážky, přece k tomu tady je. A když ne interní, tak alespoň externí. Kdo jiný by to přeci dělal, no ne? Vždyť jinak by tým nebyl efektivní.

ScrumMaster pomáhá týmu, aby si překážky odstranili sami. Facilituje diskuse, vysvětluje, coachuje a pozoruje. ScrumMaster State of Mind model je dobrým nástrojem jak na to.

Product Owner nemá být na retrospektivě. Moc by viděl, jak to děláme, a hlavně, moc by nám říkal, jak to máme dělat.

Product Owner je součástí Scrum týmů, jak jinak chceme takový tým postavit, když společně nepřemýšlíme, jak zlepšit spolupráci. Product Owner i Development tým mají jeden cíl. Dodat hodnotu zákazníkovi. Společně na tom pracují, pomáhají si a společně hledají kde se zlepšit.

Velocity a Story Pointy jsou hlavní metrikou dobré implementace Agilu. Velocity musí růst. Podle toho poznáme, že se zlepšujeme.

Agile a Scrum dávají důraz na dodání hodnoty. Story Pointy ale odhadují effort, komplexitu a risk. A to nemá s hodnotou nic společného. Určitě si umíte představit jednoduchou funkcionalitu, která přinese velkou hodnotu, a hodně komplikovanou věc, která bude mít hodnotu stejnou.

ScrumMaster by měl za tým řešit problémy. A protože to není práce na full-time, tak může být současně i členem týmu.

Cíl ScrumMastera je pomoci týmu se stát skvělým týmem. Takzvaně high-performing. Být self-organized. Nezávislý na ScrumMasterovi. Neustále hledat lepší možnosti, jak bychom mohli pracovat.

Naimplementujeme Agile a Scrum a je to. Odškrtáme pár praktik a jsme s Agilní transformací hotovi.

Agilní transformace je cesta. Cesta, kterou se učíte a neustále hledáte jiné praktiky, jak být lepší. Nikdy nebudete hotovi. Dělat Agilní praktiky nestačí. Musíte být Agilní a neustále hledat, jak se zlepšit. Vítat změny. Je to stav mysli, filosofie. Pokaždé, když dosáhnete svého cíle, který jste si na této cestě definovali, pokaždé se vám otevře obzor a vy uvidíte další nový svět kam se posunout dál.

 

Planning meeeting na 30 minut – část 2

Jak jsme již říkali v minulém článku, celý Planning meeting se komfortně vejde do 30ti minut. Pojďme se tedy podívat, jak vypadá jeho druhá část. Tým má vybrané User Story na tabuli a v rámci této fáze rozpadá jednotlivé funkcionality na konkrétní činnosti, které nebudou podle jejich předpokladu větší, než aby šly dokončit v rámci jednoho dne.

Na rozpadu pracuje celý tým najednou a paralelně plní tabuli lístečky s jednodenními tásky. Když jednotliví členové týmu rozpad dokončí, společně revidují, jestli na něco nezapomněli. Stejně jako v minulém případě, je dobré se podívat kolik tásků na tabuli vzniklo. Obecně platí, že User Story s vyšším ohodnocením se rozpadá na více drobných aktivit než menší User Story.

Ale není to matematika. Jestli jste naplánovali Sprint Backlog, kde počet lístečků odpovídá práci týmu na dva dny, máte buď příliš nízký commitment, nebo jsou jednotlivé tásky výrazně větší než jeden den, a nebo vám některé aktivity zcela chybí. Naopak, naplánovali-li jste tásků stejně jako je dnů*počet členů týmu, máte vysokou pravděpodobnost, že to nestihnete. Vždycky se něco protáhne a na něco jsme vždy zapomněli. Polovina tohoto čísla může být reálná.

Když jako tým souhlasíte s rozpadem, podíváme se ještě jednou na výsledný Sprint Backlog a eventuálně ho upravíme (přidáme / ubereme nějakou User Story) a o výsledném commitmentu informujeme Product Ownera.

Nutnou podmínkou takového rychlého Planningu je dobrá příprava. Tým nesmí vidět User Story poprvé na Planningu – už se s nimi dobře seznámil na Backlog Groomingu, kde je i ohodnotil. Zanedbat se nesmí ani příprava na rozpad User Stories na jednotlivé aktivity. Tým zná prioroty pro další Sprint několik dní dopředu a může si tak zavčas popovídat o řešení a připravit se na jejich rozpad.

Zkuste a uvidíte, že to není zas tak těžké, a že to funguje. A navíc, jako bonus ušetříte spoustu času a získáte kvalitnější Sprint commitment.

Planning meeeting na 30 minut – část 1

Často s týmy diskutuji na téma, že Scrum jsou jen samé meetingy. A tak začínám tím, že s nimi projdu, jak mají být jednotlivé meetingy dlouhé. Většinou se zasekneme na Planningu, který byste měli v pohodě zvládnout za 30 minut. Jak takový planning vypadá? Tým si nejdříve v cca 15 minutách vybere, které User Story z priorit Product Ownera by mohl dokončit. Ideální je, když opravdu fyzicky vybírá, které z kartiček na stole dá na svoji Scrum tabuli. Jednotlivé User Story a jejich business hodnotu si může tým ještě upřesnit s Product Ownerem, ale výběr je na nich.

Je tedy nasnadě, že jich Product Owner musí přinést dostatek, aby bylo z čeho vybírat. Tým tím přebírá větší zodpovědnost, a také musí produktu po všech stránkách více rozumět, než když jen bere User Stories jednu po druhé podle přesných priorit Product Ownera. Zároveň je to také často efektivnější, protože tým může vybrané User Story přizpůsobit svým zkušenostem a znalostem a optimalizovat tak dokončenou funkcionalitu v rámci priorit Product Ownera.

Fyzická reprezentace ve formě kartiček jako obvykle pomůže. Usnadňuje to týmu převzít kolektivní ownership a zodpovědnost za výběr. Jak jednotliví členové týmu navrhují, které User Stories by tým mohl stihnout, někde se to ve výběru zastaví. A členové týmu si již nejsou jisti, jestli by další věc stihli nebo ne.

Tým si může ještě udělat rychlá cross-check obvyklé velocity, když vyšlo řádově jiné číslo, tak je to dobrý indikátor k zamyšlení se, co nás vede k tomu, že toho tentokrát stihneme dvojnásobek, nebo naopak polovinu, a případné revizi návrhu Sprint Backlogu.

Tady první část Planningu končí, Product Owner i Scrum Master nechávají tým pokračovat druhou 15ti minutovou částí a odchází.

Backlog Grooming

Také se ptáte k čemu je Backlog Grooming? Cílem tohoto meetingu je zajistit, aby tým rozuměl celému Backlogu. Proto na úplně prvním Groomingu začínáme tím, že Product Owner v 15ti minutách představí vizi produktu /releasu a všechny Epicy. V druhých 15ti minutách představí střední vrstvu Backlogu, tzv. Super User Stories – tedy předpřipravené funkcionality, které přijdou na řadu za několik Sprintů. Nejsou ještě dostatečně malé ani úplně konkrétní, ale už mají obvykle formu User Story. Takových Super User Stories by mělo být připraveno na 5-10 sprintů. A zbývající čas Backlog Groomingu věnuje Product Owner konkrétním User Stories na vrcholu Backlogu. Ty už musí být INVEST, tedy jasné, konkrétní a dostatečně malé, aby se daly kdykoliv naplánovat a v rámci Sprintu dokončit. Takových User Stories potřebujeme v Backlogu na cca 2-3 Sprinty.
Backlog Grooming

Každý další Grooming už většinou Product Owner spolu s týmem prochází User Story podle priorit tak, aby měli pokaždé připraveno dostatek práce pro další Sprinty. Grooming se obvykle dělá v půlce Sprintu, aby v případě potřeby bylo dost času si danou funkcionalitu promyslet a to jak ze strany Product Ownera, tak týmu. Obvyklou součástí Backlog Groomingu je i ohodnocení User Stories Story Pointy, aby se Product Owner mohl rozhodnout na základě komplexity o prioritě, tým si ověřil, že to všichni chápou stejně a společně ev. dodefinovali akceptační kritéria, či User Story rozdělili.
Jak dlouho takový Backlog Grooming trvá? To záleží na přípravě, kterou tým jednotlivým User Stories věnuje, na připravenosti a kvalitě jednotlivých User Stories, a schopnosti efektivně komunikovat. První Groomingy obecně trvají dlouho, další mohou běžně trvat kolem 30-60minut.

Backlog Grooming

Chcete-li Grooming krátký, a navíc nemáte rádi meetingy, můžete zvážit jako tým na fotce ho dělat u tabule ve stoje. Určitě se omezí dlouhé nikam nevedoucí diskuse a posílí příprava týmu. Zároveň fyzická reprezentace umožňuje se zapojit do dodefinování User Stories každému, a nečekáte na Product Ownera až to dopíše do systému. Takže rozhodně doporučuju. Určitě to zkuste.

Správný Product Owner není úředník

Správný Product Owner má nápad, dokáže ho zformulovat do vize, a tu prodat jak zákazníkům, tak firmě i týmu, který pro něj pracuje. Spousta Product Ownerů ale je jen úředníky. Vychází z té armády business requirement specialistů, business konzultantů. Dělají to, co jim někdo řekne. To se ale přesně snažíme pomocí Agilních metod a Scrumu změnit. Proto jsme toho člověka udělali Product Ownerem, a ne jen Product úředníkem.

Jak takový produkt začíná? Ideálně si uděláme product charter. A to jak pro produkt jako takový, tak pro první release. Co to je a jaký to má formát. Je to snadné. Vše se vejde na jeden flipchart. Jméno, timeframe, elevator pitch – tedy jedna, dvě věty, které shrnují, co že to děláme a hlavně proč, vytváří obrázek, konkrétní jasnou představu cíle, vzbuzují emoce. Prostě vás zaujmou. A pak ve dvou sloupcích jako stručné odrážky cíle, kterých chcete dosáhnout a success measures, tedy jak poznáte, že jste toho dosáhli.

Product nebo Release Charter je klíčová věc. Bez ní ani nemá smysl se pouštět do psaní Backlogu a User Stories. A není to ani snadné. Když se do toho pustíte, bez ohledu na množství prezentací, které jste už o produktu vyrobili, zjistíte, že umět z toho všeho, co byste mohli dělat vydestilovat podstatu stojí čas a energii. A Product nebo Release Charter je přesně to, co vám roli Product Ownera jako člověka zodpovědného za funkcionalitu (tedy Backlog) a celkový úspěch produktu usnadní. Cílem toho “product úředníka“ z klasického světa totiž je daný nápad rozpracovat do šířky. Vymyslet co nejvíce funkcionality tak, abychom pokryli přání zákazníků a stakeholderů. Cílem Product Ownera ale je pravý opak. Nápady a přání omezit na minimální funkcionalitu, která zákazníkům přinese to, co opravdu potřebují. Dělat tedy ne to, co umíme a můžeme, ale jen to, co má nejvyšší business value. To, co potřebujeme. Jen takový produkt je potom agilní, a jen takový produkt bez ohledu na Agile a Scrum je úspěšný.