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.
