Feladatok groomingja mobilfejlesztésben: lényeg, célok és a végrehajtás folyamata

Mi a feladatok groomingja?

Backlog Grooming (refinement) — a Product Backlog feladatainak előkészítési folyamata a jövőbeli sprintekhez. Egy megbeszélés, ahol a Product Owner és a fejlesztőcsapat áttekinti a feladatokat: pontosítja a követelményeket, hozzáadja az Acceptance Criteria-t, értékeli a komplexitást, azonosítja a függőségeket és kockázatokat. A Scrum Guide-ban nincs kötelező „grooming" esemény — ez egy kiegészítő gyakorlat, amelyet a Scrum csapatok vezetnek be a Sprint Planning bizonytalanságának csökkentésére. Ajánlott gyakoriság — sprintenként 1 alkalommal, legfeljebb 60 perc.

A „fésülés" (grooming) kifejezés tükrözi a lényeget: a csapat „fésüli" a backlogot, eltávolítja az elavult feladatokat, pontosítja a homályosakat és szétbontja a túl nagyokat. A mobilfejlesztésben a grooming különösen fontos a platform-specifikusság miatt: egy Android-feladat komplexitásban eltérhet az iOS-verziótól, figyelembe kell venni a targetSdk-t, compileSdk-t, API-szintekkel való kompatibilitást. Grooming nélkül a Sprint Planning káoszba fullad: a csapat először látja a feladatokat és nem tudja azokat értékelni, ami kiszámíthatatlansághoz és késésekhez vezet.

A grooming eredménye — néhány, a Sprint Planningre kész feladat: leírással, Acceptance Criteria-val, értékeléssel rendelkeznek és megfelelnek a Definition of Readynak. A Product Ownernak prioritási sorrendben kell groomolnia a feladatokat: a jelenlegi sprinthez legközelebbiek — a legrészletesebbek. A 3-4 sprintre előre lévő feladatok — csak epik szinten. Progressive Refinement technika: minél közelebb van a feladat a sprinthez, annál részletesebb a leírása. A jelenlegi sprint feladatainál — full refinement (AC, design, API specifikáció). A 2 sprint múlva lévő feladatoknál — story-level (user story implementációs részletek nélkül). A 3+ sprint múlva lévő feladatoknál — epic-level (csak név és üzleti érték).

Definition of Ready: mikor kész a feladat a sprinthez

Definition of Ready (DoR) — azon kritériumok ellenőrzőlistája, amelyeknek a feladatnak meg kell felelnie a Sprint Backlogba való felvétel előtt. A DoR szerződés a Product Owner és a csapat között: a PO garantálja, hogy minden információ rendelkezésre áll a fejlesztéshez, a csapat garantálja, hogy értékelni és végrehajtani tudja a feladatot. A DoR nem univerzális — minden csapat meghatározza a saját kritériumkészletét. DoR nélkül a feladat homályos követelményekkel kerülhet a sprintbe, ami átdolgozáshoz és késésekhez vezet.

Tipikus DoR mobilfejlesztéshez: 1) Az Acceptance Criteria le van írva (elfogadási kritériumok Given-When-Then formátumban). 2) A design makett készen van a Figmában (UI-feladatoknál) az összes állapottal: default, loading, error, empty state. 3) Az API specifikáció jóvá van hagyva (OpenAPI/Swagger, kérés és válasz példák). 4) Az értékelés story pointokban létezik. 5) A más feladatoktól való függőségek azonosítva vannak. 6) A feladat nem függ befejezetlen külső komponensektől. 7) Mobil specifikum: a cél OS-verziók, a feature flag szükségessége, a régi API-szintek támogatása meghatározva.

Feladatértékelési technikák

Planning Poker — a legnépszerűbb értékelési technika a groomingen. Minden fejlesztő kap egy pakli kártyát Fibonacci-számokkal (1, 2, 3, 5, 8, 13, 21). A PO megmutatja a feladatot és elmagyarázza. A megbeszélés után mindenki egyszerre mutatja a kártyáját. Ha az értékelések jelentősen eltérnek (pl. 3 és 13) — a fejlesztők elmagyarázzák értékelésüket, majd újra szavaznak. Iterációk addig ismétlődnek, amíg konszenzus nem születik. A Planning Poker célja nem a pontos értékelés, hanem a feladat megértésében lévő különbségek feltárása.

T-Shirt Sizing — egyszerűsített technika gyors értékeléshez: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Alkalmas a backlog kezdeti rendezésére, amikor sok feladat van és gyorsan kell becsülni a nagyságrendet. A T-Shirt Sizing után pontosabb értékelés történik Planning Poker segítségével a következő sprint feladataira. Affinity Estimation — a feladatok csoportos rendezése relatív komplexitás alapján számok nélkül; a feladatokat az asztalra helyezik a legegyszerűbbtől a legbonyolultabbig, majd klaszterekbe csoportosítják, minden klaszter kap egy értékelést.

A mobilfejlesztésben az értékelésnek figyelembe kell vennie a platform komplexitását. Egy Android-feladat értékelhető 5 SP-re, míg ugyanaz a feladat iOS-re — 3 SP-re (vagy fordítva). Ez normális: a különböző platformok eltérő implementációs komplexitással rendelkeznek. Tipp: értékelje minden platformot külön, ha a csapat cross-platform. Használjon relatív skálát: alapfeladat (pl. egy szöveges és gombos képernyő) = 1 SP. Minden más — ehhez viszonyítva. A Scrum.org (2025) szerint 3-4 sprint után a csapat értékelési pontossága eléri a tényleges komplexitás ±20%-át.

Dekompozíció: hogyan bontsuk a nagy feladatokat

A 8 SP-nél nagyobb feladatokat kisebbekre kell bontani. A nagy feladatokat nem lehet egy sprint alatt elvégezni, nehéz értékelni és nem adnak haladásérzetet. A dekompozíció technikája: ossza fel a feladatot vízszintes rétegekre (UI → ViewModel → Repository → Network/DB) vagy függőleges metszetekre (feature: egy teljes képernyő). A vízszintes dekompozíció jobban illik a mobilfejlesztéshez: Sub-task 1 — UI elrendezés (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Egységtesztek.

Függőleges dekompozíció — a user story felvágása kisebb, független értékű történetekre. Példa: Epic „Bevásárlókosár" → Story 1 „Termék hozzáadása a kosárhoz", Story 2 „Kosár megjelenítése", Story 3 „Termék eltávolítása a kosárból", Story 4 „Rendelés leadása". Minden Story-nak saját üzleti értéke van és egymástól függetlenül kiadható. SPoK (Story Points on Kano): rendezze a Stories-t üzleti érték szerint (Must-have, Should-have, Could-have) és az érték sorrendjében implementálja.

A dekompozíció ellenőrzőlistája a groomingen: 1) A feladat nagyobb, mint 8 SP? → Bontsa fel. 2) Van Acceptance Criteria? → Ha nincs — adja hozzá. 3) Függ más feladatoktól? → Azonosítsa és jegyezze fel a függőségeket. 4) Tartalmaz bizonytalanságot? → Adjon hozzá Spike-ot (kutatás) a fő feladat előtt. 5) Szükséges design? → Ellenőrizze a makettek készségét. INVEST szabály: Independent (független másoktól), Negotiable (megbeszélhető), Valuable (értékes az üzlet számára), Estimable (értékelhető), Small (kicsi), Testable (tesztelhető). Ha a feladat nem felel meg az INVEST-nek — nem kész a sprintre.

A grooming folyamata: lépésről lépésre

1. lépés: Bemelegítés (5 perc). A Scrum Master emlékeztet a grooming céljára és a DoR-ra. A csapat a táblára néz, a PO megmutatja, mely feladatok kerülnek megbeszélésre. 2. lépés: Feladatok áttekintése (30 perc). A PO egymás után bemutatja a feladatokat a jelenlegi sprint végétől és a következő sprint elejétől. Minden feladathoz: név, leírás, Acceptance Criteria (ha van), link a designhoz, API specifikáció. A csapat pontosító kérdéseket tesz fel: „Van makett az üres állapothoz?", „Milyen HTTP metódus?", „Mi az iOS minimum deployment target?".

3. lépés: Értékelés (15 perc). A csapat értékeli a feladatot Planning Poker vagy T-Shirt Sizing segítségével. Ha az eltérés > 2 SP — megvitatják az okokat és újra szavaznak. Szabály: ha a feladat nem értékelhető (homályos követelmények, nincs design) — visszaküldik a PO-nak átdolgozásra, és pontosításokkal érkezik a következő groomingra. Ne értékeljen ismeretleneket tartalmazó feladatokat — ez garantáltan hibához vezet a sprintben. 4. lépés: Eredmények rögzítése (10 perc). A PO rögzíti az értékeléseket a Jira/Linearban, frissíti a feladat leírását és prioritásokat állít fel.

A grooming eredményei: 3-7 teljesen Sprint Planningre kész feladat (DoR-ral, értékeléssel, designnal, API-val). A PO frissíti a backlogot: eltávolítja az elavult feladatokat, összevonja a duplikátumokat, pontosítja a prioritásokat. Fontos: a grooming nem fejezi be a PO munkáját — a groomingok között elő kell készítenie a következő feladatokat. Ajánlott tempó: a PO 3-4 feladatot készít elő a groomingra, a csapat feldolgozza azokat. Ha több mint 50 feladat van a backlogban — a PO-nak priorizálást kell végeznie (MoSCoW vagy Weighted Shortest Job First) a grooming előtt.

Miben különbözik a grooming a Sprint Planningtől

Grooming — előkészítés. Nincsenek kötelezettségek — a feladatot egyszerűen pontosítják és értékelik. Sprint Planning — kötelezettségvállalás. A csapat kiválasztja a grooming során előkészített feladatokat és vállalja, hogy azokat a sprintben elvégzi. Fő különbségek: a grooming nem kötődik egy adott sprithez (általános backlog refinement), a groomingon nincs Sprint Goal, a grooming a sprint bármely pontján elvégezhető. A Sprint Planning — szigorúan a sprint elején és mindig Sprint Goalhoz vezet.

A groomingon a feladatokat csak értékelik, de nem veszik be a sprintbe. A Planningen a feladatokat kiválasztják az előkészített poolból. Grooming nélkül a Sprint Planning 6-8 óráig tart (4 helyett), mert a csapat először látja a feladatokat és nem tudja gyorsan értékelni azokat. 80/20 szabály: a Sprint Planning feladatainak 80%-a teljesen kész kell legyen (átesett groomingon), 20% — lehet új (sürgős hibák, hotfix). Ha a Planningen több mint 20% nem értékelt feladat van — a grooming nem volt elegendő.

A grooming tipikus hibái

1. hiba: grooming havonta egyszer. A csapat 3-4 sprintnyi feladatot halmoz fel, és 2 óra alatt próbál mindent pontosítani. Eredmény: a feladatok fele értékelés nélkül marad, a Planning egész napig tart. Megoldás: a groomingnak rendszeresnek kell lennie — sprintenként 1 alkalom, 60 perc. Ha sok a feladat — adjon hozzá egy második groomingot a sprint közepén. Jobb kevesebb feladatot minőségileg groomolni, mint sokat — de felszínesen. Tempó: 3-5 feladat egy grooming alkalmával, mindegyik teljes megbeszélést és értékelést kap.

2. hiba: értékelés kontextus nélkül. A PO mutatja a „Kosár képernyő megvalósítása" feladatot design, API, AC nélkül. A csapat „szemre" értékeli — 13 SP. A Planningen kiderül, hogy valójában 5 SP (mert a képernyő egyszerű). Megoldás: a feladat nem értékelhető, ha nincs design vagy API. A PO köteles anyagokat készíteni a grooming előtt. Szabály: „Nincs makett — nincs értékelés". Kivétel: Spike feladatok — a bizonytalanság kutatása, design nélkül külön értékelendők (2-5 SP a kutatás komplexitásától függően).

3. hiba: a grooming Planninggé alakul. A csapat elkezdi a feladatokat végrehajtókhoz rendelni és megbeszélni, ki mit fog csinálni. Megoldás: emlékeztetni, hogy a grooming a pontosításról szól, nem a felosztásról. A felosztás — a Daily-n a sprint megkezdése után. A grooming a „mit csináljunk?", a Planning a „mikor csináljuk?", a Daily a „ki csinálja?" kérdésre válaszol. E kérdések egy megbeszélésen való keverése csökkenti mindegyik hatékonyságát. A Scrum Masternak le kell állítania a Planning-megbeszélést és a feladat pontosítására kell irányítania a figyelmet.

4. hiba: a Tech Debt figyelmen kívül hagyása. A groomingon csak új funkciókat beszélnek meg, a technikai feladatokat figyelmen kívül hagyják. 3-4 sprint után a technikai adósság kritikus szintre nő. Megoldás: minden groomingon legalább 1 Tech feladatnak értékelésen kell átesnie. Arány: 3 funkcióra → 1 technikai feladat. Használja a Tech Debt Ratio mutatót: a Tech feladatok és a Feature feladatok aránya a sprintben. Célérték: 0.25-0.3 (az idő 25-30%-a technikai adósságra). Ha a ratio 0.2 alatt van — a fejlesztési sebesség csökkenni fog a következő sprintben.