Grooming úkolů v mobilním vývoji: podstata, cíle a proces provádění

Co je grooming úkolů?

Backlog Grooming (refinement) — proces přípravy úkolů Product Backlogu pro budoucí sprinty. Schůzka, na které Product Owner a vývojový tým procházejí úkoly: upřesňují požadavky, přidávají Acceptance Criteria, hodnotí složitost, identifikují závislosti a rizika. V Scrum Guide není povinná událost „grooming" — je to doplňková praxe, kterou Scrum týmy zavádějí pro snížení nejistoty na Sprint Planning. Doporučená frekvence — 1krát za sprint, maximálně 60 minut.

Termín „česání" (grooming) odráží podstatu: tým „češe" backlog, odstraňuje zastaralé úkoly, upřesňuje nejasné a rozděluje příliš velké. V mobilním vývoji je grooming obzvláště důležitý kvůli platformové specifičnosti: úkol pro Android se může lišit od iOS verze složitostí, je třeba zohlednit targetSdk, compileSdk, kompatibilitu s úrovněmi API. Bez groomingu se Sprint Planning mění v chaos: tým vidí úkoly poprvé a nemůže je ohodnotit, což vede k nepředvídatelnosti a zpožděním.

Výsledek groomingu — několik úkolů připravených pro Sprint Planning: mají popis, Acceptance Criteria, hodnocení a odpovídají Definition of Ready. Product Owner by měl groomovat úkoly v pořadí priority: nejbližší k aktuálnímu sprintu — nejpodrobnější. Úkoly na 3-4 sprinty dopředu — pouze na úrovni epiků. Technika Progressive Refinement: čím blíže je úkol ke sprintu, tím podrobnější je jeho popis. Pro úkoly v aktuálním sprintu — full refinement (AC, design, API specifikace). Pro úkoly za 2 sprinty — story-level (user story bez detailů implementace). Pro úkoly za 3+ sprinty — epic-level (pouze název a obchodní hodnota).

Definition of Ready: kdy je úkol připraven ke sprintu

Definition of Ready (DoR) — kontrolní seznam kritérií, kterým musí úkol odpovídat před zařazením do Sprint Backlogu. DoR je kontrakt mezi Product Ownerem a týmem: PO garantuje, že všechny informace pro vývoj jsou k dispozici, tým garantuje, že může úkol ohodnotit a provést. DoR není univerzální — každý tým si určuje vlastní sadu kritérií. Bez DoR se úkol může dostat do sprintu s nejasnými požadavky, což vede k přepracování a zpožděním.

Typický DoR pro mobilní vývoj: 1) Acceptance Criteria jsou popsána (kritéria přijetí ve formátu Given-When-Then). 2) Designová maketa je připravena v Figmě (pro UI úkoly) se všemi stavy: default, loading, error, empty state. 3) API specifikace je schválena (OpenAPI/Swagger, příklady požadavků a odpovědí). 4) Hodnocení ve story pointech existuje. 5) Závislosti na jiných úkolech jsou identifikovány. 6) Úkol není závislý na nedokončených externích komponentách. 7) Mobilní specifikum: jsou určeny cílové verze OS, potřeba feature flag, podpora starých úrovní API.

Techniky hodnocení úkolů

Planning Poker — nejoblíbenější technika hodnocení na groomingu. Každý vývojář dostane balíček karet s Fibonacciho čísly (1, 2, 3, 5, 8, 13, 21). PO ukáže úkol a vysvětlí ho. Po diskusi všichni současně ukáží kartu. Pokud se hodnocení výrazně liší (např. 3 a 13) — vývojáři vysvětlí své hodnocení a poté hlasují znovu. Iterace se opakují, dokud není dosaženo konsenzu. Smyslem Planning Poker není přesné hodnocení, ale odhalení rozdílů v chápání úkolu.

T-Shirt Sizing — zjednodušená technika pro rychlé hodnocení: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Vhodná pro počáteční třídění backlogu, když je mnoho úkolů a je třeba rychle odhadnout řád velikosti. Po T-Shirt Sizing se provádí přesnější hodnocení pomocí Planning Poker pro úkoly příštího sprintu. Affinity Estimation — skupinové třídění úkolů podle relativní složitosti bez čísel; úkoly se rozloží na stůl od nejjednodušších po nejsložitější, pak se seskupí do clusterů, každý cluster dostane hodnocení.

V mobilním vývoji musí hodnocení zohledňovat platformovou složitost. Android úkol může být ohodnocen 5 SP, zatímco stejný úkol pro iOS — 3 SP (nebo naopak). To je normální: různé platformy mají různou složitost implementace. Tip: hodnoťte každou platformu zvlášť, pokud je tým cross-platformový. Používejte relativní stupnici: základní úkol (např. obrazovka s textem a tlačítkem) = 1 SP. Vše ostatní — relativně k němu. Podle Scrum.org (2025), po 3-4 sprintech dosahuje přesnost hodnocení týmu ±20% skutečné složitosti.

Dekompozice: jak dělit velké úkoly

Úkoly větší než 8 SP by měly být dekomponovány na menší. Velké úkoly nelze splnit v jednom sprintu, jsou těžko hodnotitelné a nedávají pocit pokroku. Technika dekompozice: rozdělte úkol podle horizontálních vrstev (UI → ViewModel → Repository → Network/DB) nebo podle vertikálních řezů (feature: jedna celá obrazovka). Horizontální dekompozice je vhodnější pro mobilní vývoj: Sub-task 1 — rozvržení UI (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Unit testy.

Vertikální dekompozice — rozřezání user story na menší příběhy s nezávislou hodnotou. Příklad: Epic „Nákupní košík" → Story 1 „Přidání produktu do košíku", Story 2 „Zobrazení košíku", Story 3 „Odebrání produktu z košíku", Story 4 „Dokončení objednávky". Každá Story má svou obchodní hodnotu a může být vydána nezávisle. SPoK (Story Points on Kano): seřaďte Stories podle obchodní hodnoty (Must-have, Should-have, Could-have) a implementujte v pořadí hodnoty.

Kontrolní seznam dekompozice na groomingu: 1) Je úkol větší než 8 SP? → Dekomponovat. 2) Jsou Acceptance Criteria? → Pokud ne — přidat. 3) Závisí na jiných úkolech? → Identifikovat a zapsat závislosti. 4) Obsahuje nejistotu? → Přidat Spike (průzkum) před hlavní úkol. 5) Je potřeba design? → Zkontrolovat připravenost maket. Pravidlo INVEST: Independent (nezávislý na ostatních), Negotiable (lze diskutovat), Valuable (cenný pro business), Estimable (lze ohodnotit), Small (malý), Testable (testovatelný). Pokud úkol nesplňuje INVEST — není připraven ke sprintu.

Proces groomingu: krok za krokem

Krok 1: Zahřátí (5 minut). Scrum Master připomene cíl groomingu a DoR. Tým se podívá na tabuli, PO ukáže, které úkoly budou diskutovány. Krok 2: Přehled úkolů (30 minut). PO postupně představí úkoly z konce aktuálního a začátku příštího sprintu. Pro každý úkol: název, popis, Acceptance Criteria (pokud existují), odkaz na design, API specifikace. Tým klade upřesňující otázky: „Je maketa pro prázdný stav?", „Jaká HTTP metoda?", „Jaký je iOS minimum deployment target?".

Krok 3: Hodnocení (15 minut). Tým ohodnotí úkol pomocí Planning Poker nebo T-Shirt Sizing. Pokud je rozdíl > 2 SP — diskutují příčiny a hlasují znovu. Pravidlo: pokud úkol nelze ohodnotit (nejasné požadavky, chybí design) — je odeslán k přepracování PO a přijde na příští grooming s upřesněními. Nehodoťte úkoly s neznámými — to zaručeně povede k chybě ve sprintu. Krok 4: Záznam výsledků (10 minut). PO zaznamená hodnocení do Jira/Linear, aktualizuje popis úkolu a nastaví priority.

Výsledky groomingu: 3-7 plně připravených úkolů pro Sprint Planning (s DoR, hodnocením, designem, API). PO aktualizuje backlog: odstraňuje zastaralé úkoly, spojuje duplicitní, upřesňuje priority. Důležité: grooming neukončuje práci PO — mezi groomingy by měl připravit další úkoly. Doporučené tempo: PO připraví 3-4 úkoly pro grooming, tým je zpracuje. Pokud je v backlogu více než 50 úkolů — PO by měl provést prioritizaci (MoSCoW nebo Weighted Shortest Job First) před groomingem.

Čím se grooming liší od Sprint Planning

Grooming — je příprava. Nejsou zde žádné závazky — úkol se pouze upřesňuje a hodnotí. Sprint Planning — je závazek. Tým vybírá úkoly z připravených na groomingu a zavazuje se je splnit ve sprintu. Hlavní rozdíly: grooming není vázán na konkrétní sprint (refinement backlogu obecně), na groomingu není Sprint Goal, grooming lze provádět kdykoli během sprintu. Sprint Planning — striktně na začátku sprintu a vždy vede k Sprint Goal.

Na groomingu se úkoly pouze hodnotí, ale neberou se do sprintu. Na Planning se úkoly vybírají z připraveného poolu. Bez groomingu trvá Sprint Planning 6-8 hodin (místo 4), protože tým vidí úkoly poprvé a nemůže je rychle ohodnotit. Pravidlo 80/20: 80% úkolů na Sprint Planning by mělo být plně připraveno (prošlo groomingem), 20% — může být nových (urgentní bugy, hotfixy). Pokud je na Planningu více než 20% neohodnocených úkolů — grooming byl nedostatečný.

Typické chyby groomingu

Chyba 1: grooming jednou měsíčně. Tým nashromáždí 3-4 sprinty úkolů, snaží se vše upřesnit za 2 hodiny. Výsledek: polovina úkolů zůstává neohodnocena, Planning trvá celý den. Řešení: grooming musí být pravidelný — 1krát za sprint, 60 minut. Pokud je úkolů mnoho — přidejte druhý grooming uprostřed sprintu. Lepší je groomovat méně úkolů, ale kvalitně, než mnoho — ale povrchně. Tempo: 3-5 úkolů na jeden grooming, každý dostane plnohodnotnou diskusi a hodnocení.

Chyba 2: hodnocení bez kontextu. PO ukáže úkol „Implementovat obrazovku košíku" bez designu, bez API, bez AC. Tým hodnotí „od oka" — 13 SP. Na Planningu se ukáže, že je to ve skutečnosti 5 SP (protože obrazovka je jednoduchá). Řešení: úkol se nehodnotí, pokud není design nebo API. PO je povinen připravit materiály před groomingem. Pravidlo: „Není maketa — není hodnocení". Výjimka: Spike úkoly — průzkum nejistoty, hodnotí se samostatně bez designu (2-5 SP v závislosti na složitosti průzkumu).

Chyba 3: grooming se mění v Planning. Tým začne rozdělovat úkoly vykonavatelům a diskutovat, kdo co bude dělat. Řešení: připomenout, že grooming je o upřesnění, ne o rozdělení. Rozdělení — na Daily po začátku sprintu. Grooming odpovídá na otázku „co dělat?", Planning — „kdy dělat?", Daily — „kdo dělá?". Míchání těchto otázek na jedné schůzce snižuje efektivitu každé z nich. Scrum Master by měl zastavit Planning diskusi a přesměrovat pozornost na upřesnění úkolu.

Chyba 4: ignorování Tech Debtu. Na groomingu se diskutují pouze nové funkce, technické úkoly jsou ignorovány. Po 3-4 sprintech naroste technický dluh na kritickou úroveň. Řešení: na každém groomingu musí projít hodnocením alespoň 1 Tech úkol. Poměr: na 3 funkce → 1 technický úkol. Používejte metriku Tech Debt Ratio: poměr Tech úkolů k Feature úkolům ve sprintu. Cílová hodnota: 0.25-0.3 (25-30% času na technický dluh). Pokud je ratio pod 0.2 — rychlost vývoje bude v následujících sprintech klesat.