Grooming zadań w programowaniu mobilnym: istota, cele i proces przeprowadzania

Czym jest grooming zadań?

Backlog Grooming (refinement) — proces przygotowania zadań Product Backlogu do przyszłych sprintów. Spotkanie, na którym Product Owner i zespół programistów przeglądają zadania: doprecyzowują wymagania, dodają Acceptance Criteria, oceniają złożoność, identyfikują zależności i ryzyka. W Scrum Guide nie ma obowiązkowego wydarzenia „grooming" — to dodatkowa praktyka, którą zespoły Scrum wprowadzają w celu zmniejszenia niepewności podczas Sprint Planning. Zalecana częstotliwość — 1 raz na sprint, trwająca nie więcej niż 60 minut.

Termin „czesanie" (grooming) odzwierciedla istotę: zespół „rozczesuje" backlog, usuwając nieaktualne zadania, doprecyzowując niejasne i dzieląc zbyt duże. W programowaniu mobilnym grooming jest szczególnie ważny ze względu na specyfikę platform: zadanie dla Androida może różnić się od wersji iOS pod względem złożoności, należy uwzględnić targetSdk, compileSdk, zgodność z poziomami API. Bez groomingu Sprint Planning zamienia się w chaos: zespół po raz pierwszy widzi zadania i nie może ich ocenić, co prowadzi do nieprzewidywalności i opóźnień.

Rezultatem groomingu jest kilka zadań gotowych do Sprint Planning: mają opis, Acceptance Criteria, estymację i spełniają Definition of Ready. Product Owner powinien groomować zadania według priorytetu: najbliższe bieżącego sprintu — najbardziej szczegółowe. Zadania na 3-4 sprinty do przodu — tylko na poziomie epików. Technika Progressive Refinement: im bliżej sprintu, tym bardziej szczegółowy opis. Dla zadań w bieżącym sprincie — full refinement (AC, design, specyfikacja API). Dla zadań za 2 sprinty — story-level (user story bez szczegółów implementacji). Dla zadań za 3+ sprinty — epic-level (tylko nazwa i wartość biznesowa).

Definition of Ready: kiedy zadanie jest gotowe do sprintu

Definition of Ready (DoR) — lista kontrolna kryteriów, którym musi odpowiadać zadanie przed włączeniem do Sprint Backlogu. DoR to kontrakt między Product Ownerem a zespołem: PO gwarantuje, że wszystkie informacje do programowania są dostępne, zespół gwarantuje, że może ocenić i wykonać zadanie. DoR nie jest uniwersalny — każdy zespół określa własny zestaw kryteriów. Bez DoR zadanie może trafić do sprintu z niejasnymi wymaganiami, co doprowadzi do przeróbek i opóźnień.

Typowy DoR dla programowania mobilnego: 1) Acceptance Criteria są opisane (kryteria akceptacji w formacie Given-When-Then). 2) Projekt graficzny jest gotowy w Figmie (dla zadań UI) ze wszystkimi stanami: default, loading, error, empty state. 3) Specyfikacja API jest zatwierdzona (OpenAPI/Swagger, przykłady zapytań i odpowiedzi). 4) Estymacja w story pointach jest. 5) Zależności od innych zadań są zidentyfikowane. 6) Zadanie nie zależy od niegotowych komponentów zewnętrznych. 7) Specyfika mobilna: określone docelowe wersje systemów operacyjnych, konieczność feature flaga, wsparcie dla starych poziomów API.

Techniki estymacji zadań

Planning Poker — najpopularniejsza technika estymacji na groomingu. Każdy programista otrzymuje talię kart z liczbami Fibonacciego (1, 2, 3, 5, 8, 13, 21). PO pokazuje zadanie i wyjaśnia je. Po dyskusji wszyscy jednocześnie pokazują kartę. Jeśli estymacje znacznie się różnią (np. 3 i 13) — programiści wyjaśniają swoją ocenę, po czym głosują ponownie. Iteracje powtarzają się aż do konsensusu. Celem Planning Poker nie jest dokładna estymacja, ale wykrycie różnic w rozumieniu zadania.

T-Shirt Sizing — uproszczona technika szybkiej estymacji: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Nadaje się do wstępnego sortowania backlogu, gdy zadań jest dużo i trzeba szybko oszacować rząd wielkości. Po T-Shirt Sizing przeprowadza się dokładniejszą estymację przez Planning Poker dla zadań następnego sprintu. Affinity Estimation — grupowe sortowanie zadań według względnej złożoności bez liczb; zadania układa się na stole od najprostszych do najtrudniejszych, następnie grupuje w klastry, każdy klaster otrzymuje estymację.

W programowaniu mobilnym estymacja powinna uwzględniać złożoność platformową. Zadanie na Androida może być ocenione na 5 SP, a to samo zadanie na iOS — na 3 SP (lub odwrotnie). To normalne: różne platformy mają różną złożoność implementacji. Rada: oceniaj każdą platformę osobno, jeśli zespół jest cross-platformowy. Używaj skali względnej: zadanie bazowe (np. ekran z tekstem i przyciskiem) = 1 SP. Wszystko inne — względem niego. Według Scrum.org (2025), po 3-4 sprintach dokładność estymacji zespołu osiąga ±20% rzeczywistej złożoności.

Dekompozycja: jak dzielić duże zadania

Zadania większe niż 8 SP powinny być dekomponowane na mniejsze. Dużych zadań nie można wykonać w jednym sprincie, trudno je oceniać i nie dają poczucia postępu. Technika dekompozycji: podziel zadanie według warstw poziomych (UI → ViewModel → Repository → Network/DB) lub według przekrojów pionowych (feature: jeden ekran w całości). Dekompozycja pozioma bardziej pasuje do programowania mobilnego: Sub-task 1 — układ UI (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Testy jednostkowe.

Dekompozycja pionowa — dzielenie user story na mniejsze historie z niezależną wartością. Przykład: Epic „Koszyk zakupów" → Story 1 „Dodawanie produktu do koszyka", Story 2 „Wyświetlanie koszyka", Story 3 „Usuwanie produktu z koszyka", Story 4 „Składanie zamówienia". Każda Story ma własną wartość biznesową i może być wydana niezależnie. SPoK (Story Points on Kano): szereguj Stories według wartości biznesowej (Must-have, Should-have, Could-have) i realizuj w kolejności wartości.

Lista kontrolna dekompozycji na groomingu: 1) Zadanie większe niż 8 SP? → Dekomponuj. 2) Są Acceptance Criteria? → Jeśli nie — dodaj. 3) Zależy od innych zadań? → Zidentyfikuj i zapisz zależności. 4) Zawiera niepewność? → Dodaj Spike (badanie) przed głównym zadaniem. 5) Potrzebny design? → Sprawdź gotowość makiet. Zasada INVEST: Independent (niezależne od innych), Negotiable (można negocjować), Valuable (cenne dla biznesu), Estimable (można oszacować), Small (małe), Testable (testowalne). Jeśli zadanie nie spełnia INVEST — nie jest gotowe do sprintu.

Proces groomingu: krok po kroku

Krok 1: Rozgrzewka (5 minut). Scrum Master przypomina cel groomingu i DoR. Zespół patrzy na tablicę, PO pokazuje, które zadania będą omawiane. Krok 2: Przegląd zadań (30 minut). PO kolejno przedstawia zadania z końca bieżącego i początku następnego sprintu. Dla każdego zadania: nazwa, opis, Acceptance Criteria (jeśli istnieją), link do designu, specyfikacja API. Zespół zadaje pytania doprecyzowujące: „Czy jest makieta dla pustego stanu?", „Jaka metoda HTTP?", „Jaki iOS minimum deployment target?".

Krok 3: Estymacja (15 minut). Zespół ocenia zadanie przez Planning Poker lub T-Shirt Sizing. Jeśli różnica > 2 SP — omawiają przyczyny i głosują ponownie. Zasada: jeśli zadanie nie może być ocenione (niejasne wymagania, brak designu) — wraca do dopracowania przez PO i trafi na następny grooming z doprecyzowaniami. Nie oceniaj zadań z niewiadomymi — to gwarantowana pomyłka w sprincie. Krok 4: Zapis wyników (10 minut). PO zapisuje estymacje w Jira/Linear, aktualizuje opis zadania i ustala priorytety.

Rezultaty groomingu: 3-7 w pełni gotowych do Sprint Planning zadań (z DoR, estymacją, designem, API). PO aktualizuje backlog: usuwa nieaktualne zadania, łączy duplikaty, doprecyzowuje priorytety. Wważne: grooming nie kończy pracy PO — między groomingami powinien przygotować kolejne zadania. Zalecane tempo: PO przygotowuje 3-4 zadania na grooming, zespół je opracowuje. Jeśli zadań w backlogu jest więcej niż 50 — PO powinien przeprowadzić priorytetyzację (MoSCoW lub Weighted Shortest Job First) przed groomingiem.

Czym grooming różni się od Sprint Planning

Grooming — to przygotowanie. Nie ma na nim zobowiązań — zadanie jest po prostu doprecyzowywane i oceniane. Sprint Planning — to zobowiązanie. Zespół wybiera zadania z przygotowanych na groomingu i bierze na siebie zobowiązanie wykonania ich w sprincie. Główne różnice: grooming nie jest przypisany do konkretnego sprintu (refinement backlogu ogólnie), na groomingu nie ma Sprint Goal, grooming może odbywać się w dowolnym momencie sprintu. Sprint Planning — ściśle na początku sprintu i zawsze prowadzi do Sprint Goal.

Na groomingu zadania tylko się ocenia, ale nie są brane do sprintu. Na Planning zadania są wybierane z przygotowanej puli. Bez groomingu Sprint Planning zajmuje 6-8 godzin (zamiast 4), ponieważ zespół po raz pierwszy widzi zadania i nie może ich szybko ocenić. Zasada 80/20: 80% zadań na Sprint Planning powinno być w pełni gotowych (przeszły grooming), 20% — mogą być nowe (pilne bugi, hotfixy). Jeśli na Planning jest więcej niż 20% nieocenionych zadań — grooming był niewystarczający.

Typowe błędy groomingu

Błąd 1: grooming raz w miesiącu. Zespół gromadzi 3-4 sprinty zadań, próbując wszystko doprecyzować w 2 godziny. Rezultat: połowa zadań pozostaje nieoceniona, Planning zajmuje cały dzień. Rozwiązanie: grooming powinien być regularny — 1 raz na sprint, 60 minut. Jeśli zadań jest dużo — dodaj drugi grooming w środku sprintu. Lepiej groomować mniej zadań, ale jakościowo, niż wiele — ale powierzchownie. Tempo: 3-5 zadań na jeden grooming, każde otrzymuje pełną dyskusję i estymację.

Błąd 2: estymacja bez kontekstu. PO pokazuje zadanie „Zrealizować ekran koszyka" bez designu, bez API, bez AC. Zespół ocenia „na oko" — 13 SP. Na Planning okazuje się, że to tak naprawdę 5 SP (bo ekran jest prosty). Rozwiązanie: zadanie nie jest oceniane, jeśli nie ma designu lub API. PO ma obowiązek przygotować materiały przed groomingiem. Zasada: „Nie ma makiet — nie ma estymacji". Wyjątek: Spike-zadania — badanie niepewności, oceniane są osobno bez designu (2-5 SP w zależności od złożoności badania).

Błąd 3: grooming zamienia się w Planning. Zespół zaczyna przydzielać zadania wykonawcom i dyskutować, kto co będzie robić. Rozwiązanie: przypomnieć, że grooming dotyczy doprecyzowania, a nie przydziału. Przydział — na Daily po rozpoczęciu sprintu. Grooming odpowiada na pytanie „co robić?", Planning — „kiedy robić?", Daily — „kto robi?". Mieszanie tych pytań na jednym spotkaniu obniża efektywność każdego z nich. Scrum Master powinien zatrzymać dyskusję Planningową i skierować uwagę na doprecyzowanie zadania.

Błąd 4: ignorowanie Tech Debtu. Na groomingu omawiane są tylko nowe funkcje, zadania techniczne są ignorowane. Po 3-4 sprintach dług techniczny narasta do krytycznego poziomu. Rozwiązanie: na każdym groomingu co najmniej 1 zadanie Tech powinno przejść estymację. Proporcja: na 3 funkcje → 1 zadanie tech. Używaj metryki Tech Debt Ratio: stosunek zadań Tech do zadań Feature w sprincie. Wartość docelowa: 0.25-0.3 (25-30% czasu na dług techniczny). Jeśli ratio jest poniżej 0.2 — szybkość programowania będzie spadać w kolejnych sprintach.