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 🙂

Definition of Done

Přestože Definition of Done (DoD) je velice jednoduchý artefakt Scrumu, spousta týmů s ním zápasí.  V podstatě je to definice toho, co musí splňovat úlohy, abyste je mohli nazvat “hotovými” – tedy “done”. Je to v podstatě takový checklist definující kvalitu, kterou musí všechny úlohy na konci Sprintu splňovat, abychom je mohli považovat za hotové a ukázat je v rámci Sprint Review. Nesplňují-li některé položky Backlogu všechny části Definition of Done, nejsou hotové a musí zpět do Product Backlogu. Primárním smyslem je konzistence. Aby bylo jasné, v jakém stavu dodaný produkt je. Definition of Done vzniká jako dohoda mezi development týmem a Product Ownerem a je stejná pro všechny položky Backlogu. Na rozdíl od Akceptačních kritérií, která jsou u každé položky Backlogu různá, protože jsou funkční specifikací, je Definition of Done stejná pro všechny položky Backlogu abychom věděli, co kvalitativně musí každá funkcionalita splňovat. V dlouhodobém horizontu můžete tuto dohodu mezi týmem a Product Ownerem změnit a Definition of Done rozšířit o další pravidla a celkovou kvalitu produktu tak zvednout, ale rozhodně by se neměla měnit ze Sprintu na Sprint.

Jak taková definition of Done může vypadat?

  • Napsaný kód
  • Otestováno
  • Review
  • Dokumentace
  • Běží na test serveru
  • Akceptováno Product Ownerem

Můžete jí samozřejmě udělat specifičtější:

  • Implementováno podle Product Backlog Item (User Story) definice
  • Automaticky otestováno (unit, functional tests)
  • Review (jiným členem týmu)
  • Dokumentace (interní)
  • Beží na test serveru
  • Akceptováno Product Ownerem

A jak již bylo zmíněno, Definition of Done se vyvíjí a časem zpřísňuje:

  • Napsaný kód
  • Otestováno
  • Review
  • Dokumentace
  • Uživatelská dokumentace
  • Přeloženo do čínštiny, francouzštiny a němčiny
  • Běží na produkci
  • Obsahuje businessové metriky
  • Akceptováno Product Ownerem

V takovém případě jsme v podstatě implementovali Continuous Delivery, neboť jednotlivé funkční celky jsou releasovány na produkci už v průběhu Sprintu kdykoliv je tým dokončí – tedy splní všechny části Definition od Done. Takhle přísnou definition of Done mají týmy, které potřebují získávat zpětnou vazbu od zákazníků v reálném čase a rychle na ni reagovat. Proto businessové metriky, které měří chování zákazníka a porovnávají je s očekáváním jsou nutnou součástí takového prostředí.

Čím Agilnější vaše organizace je, tím přísnější je obvykle Definition of Done. Nezapomeňte ale, že každá Definition of Done je vždy dohodou mezi businessem a týmem a musí tedy odpovídat potřebám vašeho businessu. Přísnější není vždy lepší. 🙂 Žádná nebo slabá Definition of Done na druhou stranu zase vede k chaosu a totální ztrátě předvídatelnosti. A to byste asi nechtěli. Jako vždy v Agilu a Scrumu hledáme balanc, a tak konkrétní podobu Definition of Done musíte sami najít pomocí krátkých experimentů a principu Inspect and Adapt – tedy být Agilní.

Dnešní změna Scrum Guidu

Dnes proběhla další z dlouho očekávaných změn Scrum Guidu – tedy popisu Scrumu, který všechny kvalitní Scrum certifikační organizace společně uznávají jako základní dokument definující Scrum. Tak se pojďme podívat na změny, které tento update přinesl. Tak v první řadě dobrá zpráva je, že Scrum jako takový se mění v podstatě jen drobně. Většina změn cílí na lepší vysvětlení toho, co je Scrum a kde se používá, případně napravuje nejčastější chyby jeho pochopení.

Nově Scrum Guide definuje kontexty, kde se Scrum používá, což je zajímavý krok k tomu zbavit se nálepky “Jen pro geeky“ a ukazuje výrazný posun k “Jsme tu pro všechny činnosti, které děláte“, což je dlouhodobý trend, který je na Agile a Scrum v posledních pár letech viditelný. Pár příkladů kontextů, kde Scrum Můžete použít:

  • Research a identifikace trhu, produktu a funkcionality (tedy Scrum jde použít na věci o kterých ještě nevíme, co jsou zač a jak mají vypadat a chceme to zjistit),
  • Vývoj produktů a jejich vylepšení (tedy vytvoření něčeho o čem víme, jak má vypadat),
  • Release produktů a jejich zlepšení i několikrát denně (tedy dodávání klidně i v módu Continuous Delivery),
  • Vývoj a údržba Cloudů a jiných podobných prostředí (tedy operations a v podstatě vše co se skrývá pod buzzwordem DevOps),
  • Sustaining, maintanance a podobně.

A dodává výčet prostředí v dnes tolik skloňovaném “Scrum mimo IT” jako je například hardware, embedded software, síťová řešení, autonomní řízení, školství, státní instituce, marketing, řízení organizací a vlastně vše, co děláme v našem běžném životě.

Jako další bod nový Scrum Guide explicitněji vysvětluje ScrumMastera jako servant leadera, který se podílí na transformaci celé organizace, což je příjemná změna, která je naprosto v souladu s tím, jak roli vysvětluji na kurzech a ve své knize The Great ScrumMaster: #ScrumMasterWay.

Ale to asi nejlepší ze všech změn je, že jsme se konečně zbavili “těch třech otázek“ co všichni měli na každém Daily Scrum meetingu zvaném Standup správně používat. Co mi to vždy dalo práce lidem vysvětlit, že standup tu není kvůli hlídání individuálnímu statusu jednotlivců ani micro-managementu, ale abychom si domluvili, co budeme jako tým dělat, abychom dosáhli cíle Sprintu (Sprint Goal). Tři otázky nezmizely úplně, tedy nemusíte se bát, že jste doposud dělali všechno špatně, jen se staly jedním z doporučení jak Daily Scrum  dělat.

Jediné, co vnímám jako zvláštně nekoncepční změnu (tedy něco co odporuje trendu, že Scrum nedefinuje praktiky JAK věci máte dělat, ale CÍL kterého máte dosáhnout) je to, že Sprint Backlog má obsahovat Action steps z Retrospektivy. Chápu, že to některým týmům může pomoci, ale proč to nemáme jen jako doporučení v sekci o Retrospektivě, mi není úplně jasné. Ale třeba to časem nějak vstřebám. Ostatně, třeba to pomůže Sprint Backlogu, který po minulé změně posilující důležitost Sprint Goalu na úkor Sprint Backlogu ztratil na důležitosti, a touhle změnou zase získá zpět svůj význam.

Suma sumárum je to dobrá sada změn a přestože některé věci, které bych ráda viděla jinak, zůstávají, je Scrum Guide dobrou definicí Scrumu, která se tímto updatem stala ještě o trošinku lepší.

Jak řešit chyby ve Scrumu?

Jedním z častých dotazů, které dostávám, je jak řešit ve Scrumu chyby. Je lepší mít separátní tým na chyby a separátní tým na nový development, nebo cross-functional týmy co pracují na tom, co je zrovna potřeba, tedy chybách i nových funkcionalitách. Odpověď je snadná. Scrum optimalizuje business value. Definuje proto týmy jako cross-functional, které dokáží udělat jakoukoli změnu produktu, co přináší business value. Tedy chceme tým (týmy) co pracují na tom, co je zrovna v produktu potřeba. Ať už je to chyba, nebo nová feature.

První, co je třeba si uvědomit je, že chyba je zase jen změna funkcionality, takže není sebemenší důvod, proč by chyby nemohly jít do Backlogu jako jakékoli jiné věci, které chcete ve vašem produktu změnit. Jsou to prostě obyčejné položky Backlogu, které by měl Product Owner prioritizovat podle business value. Když dám příklad, představte si, že máte hru, kde si hráči můžou nastavovat vlastní avatary. A jedním z možných nastavení je i barva vlasů. A co čert nechtěl, pokaždé když se odhlásíte, váš avatar barvu vlasů ztratí a je zase blond. Otrava, že? Jasná chyba, řekli byste. Takže ji musíme dát do Backlogu a opravit. Dokonce na to klidně můžete použít formát User Story a napsat:

Jako hráč,

chci, aby si můj avatar pamatoval barvu vlasů,

abych ji nemusel nastavovat pokaždé znova.

Když to uděláte, stane se zajímavá věc. Z něčeho co se musí opravit, se stane něco, co má business value (abych ji nemusel nastavovat pokaždé znova) a lze prioritizovat relativně vzhledem k ostatním položkám Product Backlogu. V tomto konkrétním případě nás to donutí zjistit, kolik hráčů tuto funkcionalitu s chybou kdy použilo, ale hlavně kolika z nich vadilo, že se přes noc stali blond. A když zjistíte, že existuje jediný hráč, kterému vadí, že nemá barevné vlasy, tak možná položka do Backlogu bude úplně jiná a bude naopak znamenat odstranění funkcionality jako takové.

Co když ale chyba není takhle nedůležitá, ale je kritická? Stojí vám produkce, uživatelé nemůžou produkt používat? No tak ji opravte. Že vám to narušuje Sprint? Je to výjimečná situace, a výjimky se dějí. Když celý tým onemocní, taky to berete jako výjimku a moc to neřešíte. Je třeba si uvědomit, na co klademe důraz. V tradičním světě waterfallu bylo hlavní chybu co nejrychleji opravit. Tím jsme problém považovali za vyřešený. V Agilním světě ji opravíme, a klidně i hned jestli je tak kritická, že nepočká do dalšího Sprintu. Pak si odpočineme, a zamyslíme se, co uděláme příště pro to, aby se nám to už nestalo. Najdeme rootcause, změníme své procesy, refactorujeme, prostě uděláme cokoli, aby se takovéhle kritické chyby neobjevovaly, a ty, které nám přeci jen utečou, jsme mohli v pohodě považovat za výjimky. Protože výjimečné věci se dějí výjimečně, moc nám nevadí. Dokážeme se z toho otřepat. Stejně jako když celý tým onemocní. Naopak obvyklé věci se dějí obvykle a mohou být pěkně vyčerpávající.

Jak naplánovat Sprint bez odhadů?

Jeden z nejčastějších nešvarů Scrum implementací je odhadování tásků v hodinách a jejich následné poměřování vůči kapacitě týmu. Je to krásná myšlenka, ale v praxi je to nesmysl, který trvá zbytečně dlouho a nic nepřináší. Snad jen to, že můžete nakreslit další zbytečnost – Sprint Burndown.

Myšlenka vychází z nepochopení Scrumu. Je to pozůstatek tradičního myšlení Organizace 1.0 kde jsme věřili, že lidi alias zdroje jsou stejně jen líná banda individuí, kteří když je nebudeme hlídat, tak nic neudělají. Scrum dává práci mnohdy ztracený smysl a tak generuje daleko motivovanější lidi, kteří se sami zlepšují a vymýšlejí jak dělat věci lépe. A kteří toho udělají víc i bez mikromanagementu a detailního vykazování.

Když tedy přestaneme odhadovat kvůli kontrole lidí v týmu, zbývá se podívat, jestli mohou být takhle detailní odhady přínosné týmu samotnému. Podívejme se nejprve na reálnou přesnost takových odhadů. V podstatě, každý odhad je jen jakási předpověď. Slovní spojení ‘přesný odhad‘ je oxymoron. Nemůže nastat. Proto také ve Scrumu neodhadujeme, kdy bude jedna konkrétní věc hotová, ale kolik Product Backlog Items se nám vejde do Sprintu. Nečekané vlivy, které se týmu za Sprint stanou, se tím zprůměrují. Každá individuální story může být výrazně jiná, než jsme čekali, ale v globálu to vyjde. Jedna bude náročnější, jiná snazší, někde se zasekneme, jinde to půjde lépe, než jsme čekali a obavy se nenaplní. Jediné, co je pro plánování Sprintu potřeba, je dobré porozumění Backlogu a jednotlivým Stories. Nikdy bychom neměli do Sprintu plánovat věci, kterým nerozumíme – ale v takovém případě ani pokus o odhady tásků nepomůže.

Praktika, která týmům pomůže porozumět položkám Backlogu a na základě toho je naplánovat do Sprintu je rozpadnout Stories na tásky/aktivity, o kterých věří, že je dokáží dokončit za maximálně den (tedy od Standupu do Standupu). Některé takové tásky budou trvat třeba i tři, čtyři dny, jiné tým dokončí za pár hodin. Není důležité zkoumat tyto výjimky, ty se stanou, ať budete dělat, co budete dělat. A jestli to nejsou výjimky a všechny tásky se ukázaly být příliš malé nebo příliš velké, příští Sprint to napravte tak, aby byly v průměru dokončitelné za den. Je to zdánlivě to samé, také odhadujeme, ale je ohromný rozdíl, jestli na takovou tásku napíšete 8h a nebo se jen každý Standup z odstupu podíváte na vaší Scrum tabuli a zhodnotíte celková posun týmu. Není třeba nic počítat. Scrum je empirický proces, koriguje se sám. Někde začněte a uvidíte. Obecně je nejlepším odhadem včerejší počasí. Stačí naplánovat tolik položek Backlogu, kolik jste dokončili minule. Co se tásků týče, když vám rozpadlé aktivity vyjdou na tak cca na polovinu dní, bude to tak akorát. Obvykle se totiž některé tásky v průběhu rozpadnou na menší kousky a jiné vzniknou. To je zcela normální, neboť řešení vniká teprve v průběhu Sprintu. Zkuste to a uvidíte, jak to půjde. Příští Sprint můžete cokoli změnit tak, abyste našli správný balanc a rytmus.

Jak může vypadat Product Backlog – Příklad

Jak tak školím různé kurzy, spousta lidí se ptá, jestli mám někde příklad Product Backlogu. A já nikdy nevím jak jim vysvětlit, že je to snadné a nic složitého na tom není. Můžete začít hned. Stačí vám pro to takové ty malé podlouhlé papírové kartičky, anebo jednoduchý Microsoft Excel, či Google Sheet.

Nejjednodušší variantu Product Backlogu si můžete představit jako kartičky  (jeden sloupec Excelu), kde jednotlivé funkcionality jsou například:

Automatický výběr piva na párty
Vybrat nové pivo na ochutnání
Objednat oblíbené pivo
Doporučit drahé pivo

Jak asi víte, nejčastější formou psaní Product Backlog Items je User Story. V takovém případě Backlog obvykle rozšíříte o jméno a takzvané Conditions of Satisfaction.

Jméno
UserStory
Conditions of Satisfaction

Automatický výběr piva
Jako Jon (zaneprázdněný manager) chci, aby mi “Beerer” vybral piva na párty, abych mohl různorodým výběrem oslnit přátele.
Jon překvapí své přátele výběrem z lokálních pivovarů po celém světě a pivy různých chutí.

Vybrat nové pivo na ochutnání
Jako Jon chci zobrazit katalog piv, abych si mohl vybrat nějaké nové pivo na ochutnání.
Jon může porovnat piva podle chutí přímo z katalogu.

Objednat oblíbené pivo
Jako vracející se zákazník chci vidět oblíbená piva, abych si je mohl znovu objednat.
(může zůstat prázdné – conditions of satisfaction nejsou nutná).

Doporučit drahé pivo
Jako vlastník obchodu chci, aby “Berrer” doporučovat přednostně drahá piva, abych měl větší zisk.
Zákazníci se necítí pod tlakem moc utrácet.

Popřípadě můžete ještě přidat několik volitelných položek jako: ID, Estimate, Epic, a Priorita.

ID PBI Estimate Epic Priority
234 Automatický výběr piva na párty 20 Order 1
556 Vybrat nové pivo na ochutnání 8 Order 15
123 Objednat oblíbené pivo 3 Order 40
89 Doporučit drahé pivo 5 Profit 50

No a to je vše. Jak vidíte, není na tom nic složitého, nic co by vyžadovalo žádné komplexní nástroje složitější než podlouhlé papírové kartičky nebo Excel Sheet. Zkuste a uvidíte.

Proč je Backlog Refinement aktivita a ne meeting

Backlog Grooming se stal postupně velmi častou praktikou jak udržovat Product Backlog a rozumět jednotlivým User Stories. Týmy takový Backlog Grooming pořádají pravidelně jednou až dvakrát za Sprint, a trvá něco kolem 1-2 hodin. Když se ale podíváte na Scrum Guide, nikde se o takovém meetingu nic nedočtete. Jak tedy zajistit, že máme kvalitní Backlog a rozumíme mu bez Backlog Groomingu? Scrum Guide definuje pro tyto účely průběžně probíhající Backlog Refinement. Proč to není meeting? Protože všechny meetingy, kde musí být celý tým, jsou drahé. A když jsou dlouhé, obvykle nejsou ani moc efektivní.

Celý Backlog Refinement tedy můžete dělat jen jako sérii workshopů, kterých se účastní ti, pro které to zrovna dává smysl. Někdy je to jen malá skupinka složená z členů týmu, někdy se přidá Product Owner, jindy stakeholdeři. Vyjímečně se zúčastní všichni. Tyto workshopy děláme tak často jak je potřeba, abychom v každou chvíli měli připravený kvalitní Backlog na cca 2-3 Sprinty dopředu. Když tato aktivita probíhá dobře, tak všichni rozumí vizi produktu, vědí, jak se definuje business hodnota, mají přehled o velkých funkčnostech, které se chystají v budoucnu, a mají detailní porozumění toho, na čem budou pracovat v následujících Sprintech, jak co se týče business hodnoty tak představě o řešení problému. Jak poznáte, že je Backlog Refinement dobrý? Sprint Planning je potom jen rychlým checkem že víte, co v rámci Sprintu dokončíte, akceptace dokončených funkcionalit v rámci Sprintu Product Ownerem je formalitou, protože nevznikají nedorozumění a zákazníci jsou produktem, který na Sprint Review prezentujete spokojeni, a dávají zpětnou vazbu, která produkt zlepšuje, nikoli shazuje ze stolu.

Akceptační kritéria jsou ze starého neagilního světa

Akceptační kritéria jsou připravená odebrat se do starého železa. Už nejsou potřeba, a upřímně, nikdy to nebyl dobrý nápad. Byl to takový malý link, kterým se firmy snažily předstírat, že jsou agilní, ale mohly stále mentálně a mindsetem zůstat ve starém klasickém světě. Akceptační kritéria jsou totiž pozůstatkem detailní specifikace, kdy vývojář – rozumějme coding monkey – aby mohl začít pracovat, musel dostat detailní popis chování a řešení. Říkali jsme těm rozsáhlým dokumentům requirements a specifikace. A bez ní ani kuře nehrabe a vývojář nedá ruku na klávesnici.

Jak to že najednou nejsou potřeba? No ony vlastně nikdy nebyly. Ale zvyk je železná košile. Dělali jsme to tak vždy a tak proč v tom nepokračovat. Dodávaly nám jistotu. Měli jsme díky akceptačním kritériím pocit, že věci máme víc pod kontrolou. Že je můžeme vzít jako checklist a na konci Sprintu odškrtat, že jsme udělali vše, co bylo v zadání. Bohužel to nám ale nepomáhalo v tom mít fokus na dodání hodnoty, a týmy často jen dodaly, co tam bylo zadáno, a nepřemýšlely, jestli dosáhneme požadovaného efektu u zákazníka a v produktu.

Co tedy dělat aby to celé fungovalo? Celý tým by měl mít jasnou představu o tom, co za produkt dělá, které věci jsou z pohledu našeho businessu důležité a které ne. Toho se dá docílit tím, že se tým zapojí do visioning workshopů v rámci Backlog Refinementu, věnuje se nejen technologii, ale porozumí zákazníkovi a jeho potřebám. To je něco, o co se v Agilu snažíme už od začátků s Extreme Programmingem, kdy tím nejextrémějším kouskem XP bylo mít zákazníka v týmu. V momentě kdy tým porozumí celkovému smyslu produktu, mohou se začít podílet na jeho rozvoji. Teprve tehdy jsme vytvořili tu pravou end to end vazbu na zákazníka a změnili své vnímání vývoje softwaru z kódování na dodávání hodnoty pro zákazníka. A pak už můžeme s klidným svědomím použít User Story as a Card – tak jak byla vždy definovaná, kde důraz není kladen na detailní popis chování, ale na business hodnotu kterou dodáváme. Proto se nám vše, co potřebujeme vědět, v pohodě vejde na malou podlouhlou index kartičku. Detaily, jak této hodnoty dosáhneme, vznikají v rámci konverzace o funkcionalitě v průběhu Sprintu v době, kdy na dané UserStory tým pracuje. Výhoda konceptu UserStory as a Card je to, že udržuje Backlog jednoduchý, klade důraz na konverzaci a pomáhá týmům spolu Product Ownerem proritizovat a dodávat tu nejdůležitější hodnotu nejdříve. Kdybyste stále měli pocit, že je škoda nechat druhou stranu kartičky pro User Story prázdnou, zkuste tam napsat tzv. Conditions of Satisfaction. Rozdíl je, že takto definovaná kritéria úspěchu nejsou seznamem, co to musí dělat a jak, ale co se má stát až to naimplementujeme. Tedy jaký má věc vzbudit v zákazníkovi pocit, co má udělat, jak má produkt používat.  Je to takový funkční test, který pomáhá lépe definovat možný směr řešení, ale stále nechává volnost jak danou UserStory vyřešit.

Jako John,
si chci vybrat piva na párty,
abychom měli zajímavý výběr pití.

Akceptační kritéria by mohly vypadat následovně:

  • Výběr podle zemí, značek, druhů a chuti
  • Full text vyhledávání
  • Omezení ceny

Takto definovaný list v podstatě definuje řešení a tým už to jen slepě naimplementuje.

 

Na rozdíl od toho, když píšeme Conditions of Satisfaction, zaměříme se na hodnotu:

John vidí, nakolik jsou vybraná piva různorodá, a dostává doporučení na další piva do výběru.

Tento příklad dává větší možnost řešení ovlivnit a vymyslet něco kreativního a v podstatě dodefinovává UserStory. Zároveň se na danou funkcionalitu dívá z pohledu zákazníka, což je vždy dobře. Jak jistě víte, zákazník nemusí být vždy koncovým uživatelem, např:

Jako Beer Shop CEO,
chci zákazníkům nabízet prioritně dražší značky,
abychom měli větší zisk.

 

Conditions of satisfaction pak mohou vypadat následovně:

Zákazníci nabídky často využijí, ale necítí se pod tlakem kupovat drahá piva.

 

Takhle definované parametry úspěchu mimo jiné donutí tým napsat nějaký trackovací mechanismus jak sledovat kolikrát a kteří zákazníci nabídky využili a funkcionalitu na základě toho upravovat a zlepšovat.

Asi je to běh na dlouhou trať a nejde do něj naskočit hned. Ale je to směr, ke kterému bychom se jako industry měli blížit. Jedině tím směrem lze dosáhnout je pravé Agility a úspěchu.

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.