.st0{fill:#FFFFFF;}

Co to Backlog? 

 6 stycznia, 2018

Tomasz Dzierżek

Backlog to nic innego jak lista rzeczy do wykonania. Nie ma tutaj znaczenia czy mówimy o liście produktów do kupienia podczas najbliższej wizyty w sklepie spożywczym, czy o wymaganiach niezbędnych do zaimplementowania w systemie informatycznym. Backlog jest więc z nami codziennie czy mamy o tym świadomość, czy też nie.

 

Backlog jako Artefakt Scrum

Na początku uporajmy się z samym znaczeniem słowa „backlog”. W języku angielskim oznacza ono ni mniej ni więcej tylko „zaległości”. Jest ono nacechowane bardzo negatywnie. Sugeruje, że zbyt długo odkładaliśmy pracę, która już nie może dłużej czekać i powinniśmy się nią zająć teraz.

Im więcej ktoś ma do czynienia z metodykami agile, tym bardziej backlog to po prostu „lista rzeczy do wykonania”, niekoniecznie od razu zaległych. Nie znaczy to też, że na tej liście znajdują się tylko i wyłącznie rzeczy do zrobienia na teraz. Są tam też pomysły, życzenia i marzenia.

Prawdziwe zaległości w Scrum to dług technologiczny.

Metodyka Scrum opisuje dwa rodzaje backlogów: Backlog Produktu (ang. Product Backlog) oraz Backlog Sprintu (ang. Sprint Backlog). Oba wymienione są w części Scrum Guide dotyczącej artefaktów Scrum. Na pierwszy rzut oka (lub po pierwszej lekturze) może się wydawać, że jeden jest podzbiorem drugiego. W rzeczywistości jednak są to dwie różne listy wymagań, charakteryzujące się unikalnymi cechami.

 

Product Backlog, czyli Backlog Produktu

Gdybyśmy chcieli wytłumaczyć komuś czym jest Scrum, to Backlog Produktu pojawiłby się w jednym z pierwszych zdań. Określa on bowiem, czym tak naprawdę zajmujemy się w naszym Scrumie.

„Backlog Produktu to uporządkowana lista wszystkiego, co w danym momencie wiadomo odnośnie rozwoju produktu. Stanowi jedyne źródło wymaganych zmian, które mają być w produkcie wprowadzone.” – Scrum Guide

Product Backlog nigdy nie jest skończony. Początkowo zawiera ona najważniejsze cechy realizowanego systemu informatycznego (MVP), jednak z biegiem czasu lista ta jest uzupełniana o kolejne elementy. Tak długo jak system informatyczny żyje, w pętli Inspect and Adapt będziemy generowali nowe potrzeby. Co może się znaleźć w backlogu?

„Backlog Produktu jest listą wszystkich cech, funkcji, wymagań, ulepszeń i korekt, które reprezentują zmiany wprowadzane do produktu w jego przyszłych wydaniach.” – Scrum Guide

Backlog Produktu zawiera informacje o wszystkich wymaganiach dotyczących tworzonego systemu informatycznego. Nie ma tutaj znaczenia, czy mówimy o funkcjonalnościach, planach na rozwój systemu, wymaganiach niefunkcjonalnych czy błędach zgłoszonych przez użytkowników. Wszystko trafia do tego backlogu, nie ma więc obawy, że o czymkolwiek zapomnimy.

Co ważne, elementy Backlogu Produktu posiadają takie atrybuty jak opis, kolejność, oszacowanie i wartość. Każdy z nich jest jednakowo ważny i wspomaga zespół deweloperski w realizacji zadań, a Product Ownera w jego utrzymywaniu. Bo to on (i nikt inny) jest odpowiedzialny za ten artefakt.

 

Atrybuty Backlogu Produktu

Skoro już wspomnieliśmy o czterech atrybutach Backlogu Produktu, to wypadałoby je teraz odczarować. Na pierwszy ogień pójdzie opis, bo on jest oczywisty. Powinniśmy przecież wiedzieć co dany element oznacza i z czym się wiąże jego realizacja. Jest to punkt wyjścia do dalszych rozważań i hasłowa nazwa zwykle nie wystarcza.

Co ważne, opis nie powinien sugerować rozwiązania. Z jednej strony powinien być na tyle ogólny, żeby to Zespół Deweloperski wypracował rozwiązanie, ale z drugiej strony nie może być zbyt ogólny, żeby efekt końcowy nie odbiegał od oczekiwań odbiorców.

Wartość elementu backlogu określa jego wpływ i zarówno pozytywne konsekwencje realizacji wymagania, jak i negatywne zaniechania. Im element jest bardziej wartościowy, tym jego realizacja jest bardziej pożądana, o ile jest on wystarczająco mało skomplikowany i dobrze rozpoznany.

Mówiąc inaczej, musi on mieć odpowiednio niskie oszacowanie, czyli rozmiar. Szacowaniu (nie tylko) w Story Points poświęciliśmy osobny tekst, a przy tej okazji trzeba też koniecznie wspomnieć o technice zwanej Planning Poker. Warto też podkreślić, że jest to jedyny element, za który nie jest odpowiedzialny Product Owner. To Development Team szacuje poszczególne wymagania.

Została nam najważniejsza cecha Backlogu Produktu, czyli kolejność. Elementy w backlogu muszą być uporządkowane – jest to zadanie Product Ownera i to on wybiera kryteria, według których je układa. Zwykle jednak im element bardziej wartościowy i mniejszy tym wyżej będzie znajdował się w backlogu.

 

Backlog Sprintu

Zespół Deweloperski realizuje prace w Sprintach, czyli iteracjach trwających do miesiąca. Prognozowany zakres pracy w każdym kolejnym Sprincie, to nic innego jak Backlog Sprintu. Jak wygląda taka prognoza? Są to po prostu te elementy z Product Backlogu, które zespół stwierdził, że prawdopodobnie da radę zrobić. Ale to nie wszystko.

„Backlog Sprintu to zbiór elementów Backlogu Produktu wybranych do Sprintu rozszerzony o plan dostarczenia Przyrostu produktu i realizacji Celu Sprintu” – Scrum Guide

Sprint Backlog wzbogacony jest o „plan dostarczenia Przyrostu”, czyli o zadania do wykonania. O ile same wymagania pochodzą bezpośrednio z Product Backlogu (możemy je przenieść jeden do jednego), tak „plan dostarecznia” rozpisuje samoorganizujący się zespół. I robi to tak szczegółowo, jak jest to dla nich wygodne.

Tak jak odpowiedzialnym za Product Backlog jest Product Owner, tak Zespół Deweloperski jest odpowiedzialny za Sprint Backlog. Oznacza to, że ma on całkowitą władzę nad elementami nad którymi będzie pracował. Jeśli w czasie trwania Sprintu zachodzi potrzeba dodania, modyfikacji lub usunięcia czegoś w Backlogu Sprintu, czynność ta może być wykonana właśnie przez Zespół Deweloperski. Nie musi się on nikogo pytać o zgodę, o ile nie zmienia zakresu Sprintu.

Jeżeli istnieje potrzeba modyfikacji Sprint Backlogu w zakresie dodania lub usunięcia wymagań (a tak naprawdę Elementów Backlogu Produktu czyli Product Backlog Items), to też jest taka możliwość. Ale każda tego typu modyfikacja musi się odbywać za wiedzą Product Ownera.

Zapisywanie backlogu na kartce.
Jeżeli elementy nie są uporządkowane, to jest to zwykła lista  To-Do.

 

Szczegółowy Sprint Backlog

Podczas Planowania Sprintu zwykle nie będziemy w stanie określić wszystkich akcji i zadań („planu dostarczenia”) niezbędnych do zrealizowania kompletu wymagań. Oznacza to, że zakres prac będzie krystalizował się w miarę realizacji zaplanowanych zadań. Stąd modyfikacje Backlogu Sprintu są nieuniknione – ciągle poznajemy więcej szczegółów o pracy czekającej na nas w ramach bieżącego Sprintu.

Backlog Sprintu powinien być na tyle szczegółowy, aby możliwa była praca z nim podczas codziennego spotkania Daily Scrum Meeting. Zbyt duża szczegółowość Backlogu Sprintu spowoduje problemy z bieżącą pracą, zbyt mała – problemy z identyfikacją niezbędnych do wykonania zadań.

Co ważne, poprzez wybór zakresu prac do wykonania podczas w Planowania Sprintu, zespół deweloperski prognozuje, które elementy Backlogu Produktu będą dostarczone na koniec Sprintu i jednocześnie staną się częścią potencjalnie wdrażalnego przyrostu produktu.

Pamiętajmy, że w trakcie Planowania Sprintu powstaje prognoza, a nie zobowiązanie, plan czy nawet szacunek.

 

Forma wymagań w backlogu

Product Backlog powinien być prowadzony w formie fizycznej listy. Nie ma tutaj znaczenia, czy będzie to lista prowadzona na papierze, w aplikacji, czy w arkuszu Excel. Ważne, aby wgląd do listy mieli wszyscy zainteresowani rozwojem systemu, zgodnie z podstawową zasadą Scruma – transparentnością.

Podobnie sprawa ma się z Backlogiem Sprintu. Może on posiadać dowolną formę, jednakże dobre praktyki wskazują na potrzebę prowadzenia go w taki sposób, aby podczas Daily Scrum Meetingu możliwe było bezproblemowe do niego zerknięcie. Wyciąganie laptopa i podłączanie się pod rzutnik jest zbyt dalekie od „bezproblemowego”, stąd zespoły często stawiają na Scrum Board, czyli tablicę.

Nie ma tutaj znaczenia w jakiej konkretnie postaci zapisujemy poszczególne elementy obu backlogów. Chociaż User Story to już prawie standard jeżeli chodzi o Product Backlog, to nigdzie w Scrum Guide nie pada nawet taka sugestia. Zgodnie z ideą samoorganizacji, to Scrum Team decyduje, w jakiej postaci będzie utrzymywał backlogi.

Bo nie ulega wątpliwości, że zapisanie wymagań w postaci backlogu pozwoli na zarządzanie pracą w lepiej zorganizowany, scrumowy sposób.

 

Twój osobisty Backlog

Backlog to nie każda lista czynności do wykonania, tylko taka, która jest przynajmniej uporządkowana, a jeszcze lepiej – jeśli ma przypisane wartości i oszacowania (patrz: Refinement).

Zwykła lista ToDo jest nieuporządkowana, a jej elementy nie mają przypisanej wartości. Jeśli jednak podzielimy ją na „muszę zrobić dzisiaj”, „muszę zrobić w tym tygodniu” i „może poczekać”, to już będzie lepiej. A gdy o każdego zadania przypiszemy jego wartość np. malując od jednej do pięciu gwiazdek, powstanie nam backlog.

A z nim pracuje się o wiele lepiej, bo jest bardziej elastyczny – czasami skupiamy się na rzeczach ważniejszych kosztem tych mniej znaczących, a gdy mamy więcej czasu – zabieramy się za skomplikowane zadania. Nie zastanawiamy się, co teraz powinniśmy zrobić, bo wystarczy rzut oka.

Jeśli na szczycie naszej listy ToDo zawsze znajdują się zadania do wykonania w pierwszej kolejności, to już jest ona bardziej „backlogowa”.

Nie od dziś wiadomo, że udając się do sklepu z wcześniej przygotowaną listą zakupów wydamy mniej pieniędzy na niepotrzebne produkty i zrobimy celniejsze zakupy niż idąc bez listy. Backlog „zakupowy” zawierać będzie zapewne zarówno produkty niezbędne (must-have) jak i dodatkowe (wish-list). Uporządkowanie tych produktów na liście spowoduje, że skupimy się na zakupie właściwych. Sam się o tym wielokrotnie przekonałem.

 

Jeżeli powyższy tekst to wciąż mało, sprawdź nasze szkolenia. W szczególności polecamy nasze popularne warsztaty „Wymagania w projektach agile„. Pokazujemy tam jak pracować z backlogiem, wymaganiami, User Stories i nie tylko.

Tomasz Dzierżek


23+ lat doświadczenia w IT, 15+ lat doświadczenia w Scrum i agile, PSM III (i inne), konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}