Backlog produktu zawiera 400 zadań. Połowa z nich ma rok. Nikt nie wie, które są ważne, które nieaktualne, a które ktoś dodał „na wszelki wypadek". Sprint planning trwa trzy godziny, bo za każdym razem trzeba od nowa ustalać, co właściwie powinno być zrobione.
To nie jest backlog - to wysypisko zadań. I niestety większość zespołów zna ten problem z własnego doświadczenia.
Zarządzanie backlogiem to jedna z kluczowych kompetencji product ownera i project managera. Dobrze prowadzony backlog sprawia, że sprint planning trwa 45 minut, a cały zespół wie, co i po co robi.
Czym jest backlog produktu
Backlog produktu (ang. product backlog) to uporządkowana lista wszystkiego, co powinno zostać zrobione w projekcie. Zawiera funkcje, poprawki, ulepszenia, zadania techniczne i wszystko inne, co może wejść do przyszłych sprintów.
Backlog jest żywym dokumentem - zmienia się, gdy zmienia się produkt, rynek lub priorytety biznesowe. Nie jest to lista rzeczy do zrobienia napisana raz i zapomniana.
W backlogu powinny znaleźć się: user stories, bugi, zadania techniczne, usprawnienia UX i spike'i (zadania badawcze). Nie powinno być: zadań, które na pewno nie zostaną zrobione w ciągu 6 miesięcy, zduplikowanych zadań ani zadań bez żadnego opisu.
Backlog produktu a backlog sprintu
Backlog produktu zawiera wszystko, co może zostać zrobione - zarządza nim product owner, z perspektywą długoterminową. Backlog sprintu zawiera to, co zostanie zrobione w tym sprincie - zarządza nim cały zespół deweloperski, z perspektywą jednego sprintu. Zmiany w backlogu produktu są możliwe w trakcie sprintu; zmiany w backlogu sprintu są minimalizowane.
Jak tworzyć dobre wpisy w backlogu
User stories
User story to format opisu funkcji z perspektywy użytkownika: „Jako [typ użytkownika], chcę [akcja], żeby [cel]." Przykład: „Jako menadżer projektu, chcę filtrować zadania po assignee, żeby szybko zobaczyć, nad czym pracuje konkretna osoba." User stories skupiają uwagę na wartości dla użytkownika, a nie na szczegółach implementacji.
Acceptance criteria
Każda user story powinna mieć acceptance criteria - konkretne warunki, które muszą być spełnione, żeby zadanie było uznane za ukończone. Bez acceptance criteria „gotowe" znaczy co innego dla developera, co innego dla testera i co innego dla product ownera.
Definition of Ready
Zanim zadanie trafi do sprintu, powinno spełniać Definition of Ready: ma tytuł i opis, ma acceptance criteria, jest estymowane, nie jest blokowane przez inne zadania, zespół rozumie, co trzeba zrobić. Zadania, które nie spełniają Definition of Ready, nie powinny trafiać do sprint planning.
Priorytetyzacja backlogu - metody
MoSCoW
Prosta metoda podziału zadań na cztery kategorie: Must have - musi być zrobione; Should have - ważne, ale nie krytyczne; Could have - fajne, jeśli będzie czas; Won't have - na razie nie robimy. Uwaga: tendencja do przypisywania wszystkiego do „Must have" jest główną słabością tej metody.
RICE
RICE to metoda ilościowa: Reach (ilu użytkowników dotknie zmiana), Impact (jak duży wpływ, skala 0,25-3), Confidence (jak pewni jesteśmy szacunków, 0-100%), Effort (ile osoba-miesięcy zajmie implementacja). Wzór: (Reach × Impact × Confidence) / Effort. Wyższy wynik = wyższy priorytet. RICE jest szczególnie przydatny przy porównywaniu wielu zadań obiektywnie.
Model Kano
Kano dzieli funkcje na trzy kategorie: Must-be - funkcje, których brak frustruje użytkowników; Performance - im lepsze, tym bardziej zadowoleni użytkownicy; Delighters - funkcje, których użytkownicy się nie spodziewają, ale które ich zachwycają. Kano pomaga zrozumieć, które funkcje są podstawowe, a które mogą wyróżnić produkt na tle konkurencji.
Jak często robić refinement backlogu
Refinement backlogu to regularne spotkanie, na którym zespół przegląda, uzupełnia i aktualizuje backlog przed sprint planning. Sprawdza się refinement raz w tygodniu lub raz na sprint, maksymalnie 10% czasu sprintu.
Podczas refinementu: dodajemy opisy i acceptance criteria, dzielimy duże zadania na mniejsze user stories, usuwamy zduplikowane lub nieaktualne zadania, estymujemy zadania do kolejnego sprintu, aktualizujemy priorytety. Uczestniczą: product owner, zespół deweloperski, Scrum Master (moderuje).
Estymowanie zadań
Story points to jednostka miary relatywnej złożoności zadania, a nie czasu. Zadanie wycenione na 5 punktów jest mniej więcej dwa razy bardziej skomplikowane niż zadanie wycenione na 3 punkty.
Planning poker: każdy członek zespołu jednocześnie pokazuje swoją ocenę (np. karty ze skali Fibonacciego). Jeśli oceny się różnią, dyskutujcie, dlaczego - różnica często ujawnia nieporozumienia co do zakresu zadania.
Najczęstsze błędy w zarządzaniu backlogiem
Backlog jako lista życzeń. Backlog zawierający 500 zadań bez priorytetyzacji jest bezużyteczny. Regularnie usuwaj zadania, które nie będą realizowane.
Niejasne zadania trafiające do sprintu. Stosuj Definition of Ready i nie wpuszczaj do sprintu zadań, które go nie spełniają.
Brak regularnego refinementu. Zaniedbany backlog szybko się dezaktualizuje. Traktuj refinement jak inne ceremonie Scruma.
Ignorowanie długu technicznego. Dług techniczny to też element backlogu. Jeśli nigdy nie trafia do backlogu, nigdy nie zostanie zrealizowany. Więcej w artykule Dług techniczny - czym jest i jak nim zarządzać.
Za duże zadania. Każde zadanie powyżej 8 punktów rozbij na mniejsze. Dobrze napisane zadanie można zamknąć w ciągu 1-2 dni.
Zarządzanie backlogiem w Taskello
W Taskello backlog to widok, w którym możesz gromadzić wszystkie zadania przed przypisaniem ich do sprintu. Możesz tworzyć etykiety, ustawiać priorytety i filtrować zadania według dowolnych kryteriów.
Podczas refinementu cały zespół może jednocześnie pracować na backlogu - dodawać opisy, komentarze, estymacje - bez konieczności organizowania oddzielnych spotkań. Sprawdź, jak zarządzać projektami w Taskello od podstaw, w artykule Jak zarządzać projektami w Taskello - instrukcja krok po kroku.
Backlog w metodykach zwinnych
Jeśli chcesz zrozumieć, jak backlog wpisuje się w szerszy kontekst Scruma, przeczytaj Scrum - kompletny przewodnik dla początkujących. Jeśli pracujesz metodą Kanban, sprawdź nasz artykuł o tym, czym jest Kanban i komu się sprawdzi. O priorytetyzacji przeczytasz w artykule Priorytetyzacja zadań - sprawdzone metody.
Podsumowanie
Kluczowe zasady zarządzania backlogiem:
- Backlog powinien być krótki i aktualny - regularnie usuwaj nieaktualne zadania.
- Każde zadanie musi mieć opis, acceptance criteria i być estymowane przed wejściem do sprintu.
- Refinement to konieczność, nie opcja.
- Priorytetyzuj metodycznie: MoSCoW, RICE lub Kano.
- Dług techniczny należy do backlogu tak samo jak nowe funkcje.
Chaos w backlogu to chaos w całym projekcie. Porządek w backlogu to spokojny sprint planning i zespół, który wie, co i po co robi.
