Otworzyłem backlog projektu MediFlow - systemu rejestracji online dla 12 przychodni - w trzecim miesiącu prac. 312 pozycji. Pierwsza z brzegu: „Poprawić rejestrację". Bez opisu, bez kryteriów, dodana cztery miesiące wcześniej przez kogoś, kto już nie pracował w projekcie. Dalej trzy pozycje opisujące to samo innymi słowami, jedna o funkcji, którą wycofano, i czternaście oznaczonych priorytetem „Krytyczny". Kiedy wszystko jest krytyczne, nic nie jest. Ten backlog nie był narzędziem planowania - był archeologicznym wykopaliskiem.
Backlog produktu to nie lista życzeń, którą się tylko powiększa. To żywy, uporządkowany plan, który wymaga ciągłej pielęgnacji. W tym artykule pokażę Ci trzy filary prowadzenia backlogu - utrzymanie porządku, doprecyzowanie (refinement) i priorytetyzację - z konkretnymi przykładami „źle → dobrze", tabelą technik i pułapkami, w które wpada większość zespołów. Po drodze rozwieję częste zamieszanie terminologiczne wokół słowa „grooming".
Czym jest backlog produktu i kto za niego odpowiada
Backlog produktu to jedyne, uporządkowane źródło prawdy o tym, co może trafić do produktu: funkcje, usprawnienia, poprawki błędów, zadania techniczne. Jest dynamiczny - zmienia się z każdym sprintem, w miarę jak zespół uczy się o produkcie i użytkownikach.
Za backlog odpowiada Product Owner - to on decyduje o zawartości i kolejności. Ale w praktyce, zwłaszcza przy złożonych domenach jak ochrona zdrowia, najwięcej pracy nad doprecyzowaniem pozycji wykonuje analityk biznesowy. Jak dokładnie dzielą się tą odpowiedzialnością, opisuję w artykule analityk biznesowy vs Product Owner.
Uwaga terminologiczna: słowo „grooming" wyszło z użycia w oficjalnym Scrumie (ma niefortunne konotacje) i zostało zastąpione terminem refinement (doprecyzowanie). W Scrum Guide nie jest to osobne wydarzenie, lecz ciągła aktywność. W tym artykule używam „refinement" jako terminu nadrzędnego, a „porządkowanie" dla bieżącego czyszczenia listy.
Filar 1: utrzymanie porządku w backlogu
Backlog bez regularnego czyszczenia staje się tym, co znalazłem w MediFlow - wysypiskiem. Porządkowanie to cztery proste czynności, które najlepiej robić w krótkich, częstych sesjach.
- Usuwaj bez litości. Pozycje nieaktualne, zdublowane, opisujące wycofane funkcje - kasuj. W MediFlow „Integracja z faksem rejestracji" wisiała pół roku. Faks zniknął z procesu. Pozycja poszła do kosza.
- Aktualizuj opisy. Wymagania się zmieniają. Co kwartał przejrzyj starsze pozycje i sprawdź, czy nadal opisują rzeczywistość.
- Dziel grube pozycje. „Poprawić rejestrację" to nie pozycja, to temat. Rozbij na konkretne: „Skrócić formularz rezerwacji do 4 pól", „Dodać walidację numeru PESEL", „Pokazywać najbliższy wolny termin na górze listy".
- Szacuj zgrubnie. Wstępna ocena rozmiaru (małe/średnie/duże) pomaga w priorytetyzacji i planowaniu, jeszcze zanim dojdzie do dokładnej wyceny.
Filar 2: refinement - doprecyzowanie szczegółów
Refinement to moment, w którym pozycja backlogu zamienia się z hasła w coś, co zespół może bezpiecznie wziąć do sprintu. Robisz to tylko dla pozycji bliskich realizacji - doprecyzowanie czegoś, co wejdzie za pół roku, to strata czasu, bo wymagania i tak się zmienią.
Jak wygląda dobrze zrefinowana pozycja - źle vs dobrze
| Źle (hasło) | Dobrze (zrefinowana) | |
|---|---|---|
| Tytuł | Walidacja NFZ | Weryfikacja uprawnień NFZ przy rezerwacji refundowanej |
| Opis | (brak) | Jako pacjent chcę, by system sprawdził moje uprawnienia w eWUŚ, aby wiedzieć, czy wizyta jest refundowana, zanim ją potwierdzę. |
| Kryteria akceptacji | (brak) | System odpytuje eWUŚ po PESEL; przy potwierdzonych uprawnieniach oznacza wizytę jako refundowaną; przy braku odpowiedzi pozwala rezerwować i oznacza „do weryfikacji"; czas odpowiedzi ≤ 3 s. |
| Zależności | (nieznane) | Wymaga konektora eWUŚ (osobna pozycja, musi być pierwsza). |
| Estymacja | (brak) | 8 punktów (po Planning Pokerze z całym zespołem). |
Cztery rzeczy do zrobienia podczas refinementu: omów wymaganie (czy wszyscy rozumieją cel?), spisz kryteria akceptacji (jak poznamy, że gotowe?), wykryj zależności i ryzyka (co musi być pierwsze? co może nas zaskoczyć?) i oszacuj pracochłonność (np. Planning Pokerem, by zaangażować cały zespół). Dobre kryteria akceptacji to osobna sztuka - rozwijam ją w artykule o pisaniu kryteriów akceptacji.
Definicję „gotowości pozycji do sprintu" warto sformalizować jako Definition of Ready - checklistę, którą musi spełnić historyjka, zanim zespół ją weźmie. Typowo: ma opis, ma kryteria akceptacji, jest oszacowana, nie ma nierozwiązanych zależności, mieści się w jednym sprincie.
Filar 3: priorytetyzacja - co najpierw
Priorytetyzacja to nie układanie listy „od najważniejszego". To podejmowanie decyzji o kompromisach: jeśli to wejdzie, tamto wypadnie z najbliższego sprintu. Bez świadomej priorytetyzacji zespół robi to, co najgłośniej krzyczy, a nie to, co przynosi największą wartość.
Techniki priorytetyzacji - którą wybrać
| Technika | Na czym polega | Kiedy użyć |
|---|---|---|
| MoSCoW | Must / Should / Could / Won't have | Szybki podział na poziomy konieczności, np. przy ustalaniu zakresu MVP |
| Value vs Effort | Macierz wartość biznesowa kontra koszt wdrożenia | Gdy szukasz „szybkich zwycięstw" (wysoka wartość, niski koszt) |
| WSJF | Cost of Delay podzielony przez rozmiar zadania | Gdy potrzebujesz obiektywnej kolejności w dużym backlogu |
| Model Kano | Podział funkcji na podstawowe, oczekiwane i zachwycające | Gdy projektujesz produkt i ważą się decyzje o przewadze rynkowej |
Nie ma jednej najlepszej techniki - dobierasz do sytuacji. MoSCoW i WSJF to dwa robocze konie analityka; ich praktyczne porównanie i poprawne liczenie WSJF (bo połowa internetu liczy to źle) opisuję w artykule o priorytetyzacji MoSCoW i WSJF.
Trzy zasady dobrej priorytetyzacji
- Ustal jawne kryteria. Wartość biznesowa, koszt, ryzyko, pilność, zgodność z prawem. W MediFlow zgodność z RODO miała najwyższy priorytet niezależnie od wartości - bo brak zgodności blokuje wszystko.
- Angażuj interesariuszy. Priorytety bez głosu użytkowników i biznesu to zgadywanie. Ale uwaga: angażuj ich do kryteriów i danych, decyzję podejmuje PO - inaczej priorytetyzacja zamienia się w przeciąganie liny.
- Bądź elastyczny. Priorytety żyją. Nowa regulacja, awaria, feedback z produkcji - wszystko może je przewrócić. Backlog to żywy organizm, nie kamienna tablica.
Rytm pracy z backlogiem
Kiedy robić co? Oto rytm, który sprawdza się w większości zespołów dwutygodniowych:
- Porządkowanie - na bieżąco, plus krótki przegląd raz w tygodniu (15-30 min).
- Refinement - regularnie, najlepiej raz w tygodniu lub raz na sprint, tuż przed planowaniem. Cel: mieć zrefinowane pozycje na 1-2 sprinty do przodu.
- Priorytetyzacja - raz na sprint przy mniejszych korektach, głębszy przegląd raz na kwartał lub przy istotnej zmianie strategii.
Złota zasada: krótkie i częste bije długie i rzadkie. Trzygodzinny maraton refinementu raz na miesiąc wyczerpuje zespół i daje gorsze efekty niż 45 minut co tydzień.
Mini-case MediFlow: od wykopaliska do narzędzia
Jak posprzątaliśmy te 312 pozycji:
- Czyszczenie: usunęliśmy 80 pozycji (duplikaty, wycofane funkcje, hasła bez kontekstu). Zostało 232.
- Grupowanie: zebraliśmy podobne pozycje w epiki (np. „Rezerwacja", „Weryfikacja NFZ", „Powiadomienia"). Backlog stał się czytelny.
- Priorytetyzacja MoSCoW: „Must have" na MVP - rezerwacja, weryfikacja NFZ, potwierdzenie SMS. „Won't have (teraz)" - integracja z aplikacją mobilną, którą odłożyliśmy o rok.
- Refinement najbliższych: dla pozycji „Must have" spisaliśmy kryteria akceptacji, wykryliśmy, że konektor eWUŚ musi być pierwszy, oszacowaliśmy Planning Pokerem.
- Definition of Ready: ustaliliśmy, że żadna pozycja nie wchodzi do sprintu bez opisu, kryteriów i estymacji.
Efekt: zespół przestał kłócić się na planowaniu o to, co właściwie znaczy dana pozycja. Backlog z archiwum zamienił się w plan. To nie była praca techniczna - to była praca analityczna.
Częste błędy w prowadzeniu backlogu
- Backlog jako wysypisko. Tylko dodajesz, nigdy nie usuwasz. Po roku nikt go nie ogarnia, a wartościowe pozycje toną w szumie.
- Refinement wszystkiego. Doprecyzowujesz pozycje na pół roku do przodu. Marnujesz czas, bo wymagania się zmienią - refinuj tylko najbliższe 1-2 sprinty.
- „Wszystko jest priorytetem". Czternaście pozycji „Krytyczny" to brak priorytetyzacji. Jeśli każda jest najważniejsza, zespół wybiera po cichu sam - zwykle źle.
- Refinement jako monolog PO. Product Owner czyta pozycje, zespół przytakuje. Refinement to dialog - to deweloperzy wyłapują zależności techniczne, a tester pyta „jak to przetestować".
- Estymacja jako zobowiązanie. Mylenie wstępnego szacunku z obietnicą terminu. Estymacja to narzędzie planowania, nie kontrakt.
- Brak Definition of Ready. Pozycje wchodzą do sprintu niedoprecyzowane, zespół utyka w połowie, bo „nie wiadomo, co dokładnie zrobić".
FAQ - prowadzenie backlogu
Czym różni się grooming od refinementu?
To dwie nazwy na praktycznie to samo - doprecyzowanie i pielęgnację backlogu. „Grooming" to starszy termin, wycofany z oficjalnego Scruma na rzecz „refinementu" ze względu na niefortunne konotacje słowa. W praktyce możesz traktować je jako synonimy.
Czy refinement to wydarzenie w Scrumie?
Nie. Scrum Guide opisuje refinement jako ciągłą aktywność, nie jako jedno z pięciu wydarzeń. Wiele zespołów planuje na nią regularny czas (np. raz na sprint), ale formalnie nie jest to osobne, obowiązkowe wydarzenie.
Jak często prowadzić refinement backlogu?
Regularnie i w krótkich sesjach - najlepiej raz w tygodniu lub raz na sprint, tuż przed planowaniem. Cel: mieć zrefinowane pozycje na 1-2 sprinty do przodu. Częste, krótkie sesje są skuteczniejsze niż rzadkie maratony.
Kto decyduje o priorytetach w backlogu?
Product Owner - to jego formalna odpowiedzialność. Analityk i interesariusze dostarczają danych i kryteriów, użytkownicy wnoszą perspektywę, ale ostateczną decyzję o kolejności podejmuje PO. Inaczej priorytetyzacja zamienia się w przeciąganie liny. Jeśli zastanawiasz się, którą z tych ról wybrać dla siebie, przygotowałem autodiagnozę w tekście analityk biznesowy a Product Owner - którą rolę wybrać.
Co to jest Definition of Ready?
To checklista warunków, które pozycja backlogu musi spełnić, zanim zespół weźmie ją do sprintu - zwykle: ma opis, kryteria akceptacji, jest oszacowana, nie ma nierozwiązanych zależności i mieści się w jednym sprincie. Chroni przed wpadaniem niedoprecyzowanych pozycji do realizacji.
Podsumowanie
Dobrze prowadzony backlog to różnica między zespołem, który buduje właściwe rzeczy we właściwej kolejności, a zespołem, który gasi pożary i kłóci się o znaczenie haseł. Trzy filary - porządkowanie, refinement i priorytetyzacja - to nie biurokracja, lecz codzienne rzemiosło analityka i Product Ownera.
Zapamiętaj trzy rzeczy: usuwaj odważnie (backlog to nie archiwum), refinuj tylko najbliższe (reszta się zmieni) i priorytetyzuj jawnymi kryteriami (nie „na czuja"). Reszta to kwestia rytmu, który wypracujesz z zespołem.
Chcesz opanować priorytetyzację na poziomie, który robi różnicę? Zacznij od porównania MoSCoW i WSJF, a potem przećwicz pisanie user stories z kryteriami akceptacji w testach na platformie Analify.