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.