Backlog sprintu

Backlog sprintu
Polecane artykuły

Backlog sprintu – w metodyce SCRUM, jest to zbiór zadań wybranych z backlogu produktu, który jest realizowany w danym sprincie. Ustalany jest on przed rozpoczęciem sprintu, podczas jego planowania. W przeciwieństwie do backlog produktu, który składa się zazwyczaj z historyjek użytkownika, backlog sprintu zawiera listę konkretnych zadań do wykonania przez zespół deweloperski w trakcie sprintu[1].

Wszystkie zadania w backlogu bieżącego sprintu powinny zawierać następujące informacje[2]:

  • opis danego zadania, w tym również informacja o historyjce użytkownika, z której się wywodzi,
  • szacowany czas wykonania zadania,
  • członka zespołu odpowiedzialnego za wykonanie zadania (jeżeli jest ono już realizowane),
  • status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane).

Etapy tworzenia Backlogu sprintu

Backlog Sprintu jest wynikiem planowania sprintu, w którym udział biorą Zespół deweloperski, Product owner i Scrum master[3]. Tworzony jest w następujących krokach[4]:

1. Wybór historyjek użytkownika z backlogu produktu

Zespół ustala, które historyjki zawarte w backlogu produktu zostaną zrealizowane w trakcie najbliższego sprintu. Przy wyborze brane są pod uwagę następujące zagadnienia:

  • cel sprintu, który został ustalony przez zespół na początku planowania,
  • priorytety historyjek (ustalone w trakcie tworzenia backlogu produktu) – zazwyczaj zespół stara się zrealizować w pierwszej kolejności historyjki z najwyższym priorytetem,
  • szybkość działania zespołu – w jakim tempie pracują członkowie zespołu, a więc ile pracy będą w stanie wykonać w czasie trwania sprintu. Tutaj możliwe są dwie metody szacowania:
- na podstawie prędkości realizowania zadań w poprzednim sprincie,
- na podstawie dostępności zespołu, a więc informacji o tym, ile czasu każdy członek zespołu będzie pracował w danym projekcie.

2. Podział na zadania

Każdą historyjkę, która została wybrana do sprintu, zespół dzieli na pojedyncze zadania do wykonania. Zadania powinny mieć następujące cechy:

  • być możliwe do wykonania przez jedną osobę,
  • czas wykonania jednego zadania nie powinien przekraczać 8 godzin,
  • wykonanie wszystkich zadań dla danej historyjki skutkuje automatycznym "zamknięciem” historyjki,
  • mieć rzeczywistą wartość dla realizacji projektu – do backlog sprintu powinny trafiać tylko zadania mające realny wpływ na projekt; nie dodajemy więc do backlogu zadań związanych np. z rekrutacją, czy spotkaniami organizacyjnymi.

Przykładowe typy zadań, na jakie może zostać podzielona historyjka[5]:

  • przygotowanie dokumentacji,
  • projekt UI,
  • planowanie testów,
  • automatyzacja testów,
  • implementacja,
  • spotkania z właścicielem produktu,
  • bufor,
  • przygotowanie przypadków testowych,
  • przegląd kodu,
  • testy,
  • poprawa błędów.

3. Szacowanie zadań

Dla każdego zadania, które zostało zdefiniowane w poprzednim kroku, zespół ustala przewidywalny czas jego wykonania w godzinach idealnych, a więc ile godzin zajmie wykonanie tego zadania jednej osobie, w warunkach idealnych. Jeżeli dane zadanie zostanie oszacowane na ponad 8 godzin (jeden dzień roboczy), należy się wówczas zastanowić, czy nie byłoby zasadne rozbicie go na kilka mniejszych – zwłaszcza, jeżeli szacowana długość realizacji jest kilkukrotnie większa niż 8 godzin.

Zadania powinny być szacowane wspólnie przez cały zespół, a nie przez jego pojedynczych członków, bez porozumienia z pozostałymi.

Przykładowym narzędziem, które można wykorzystać do szacowania zadań jest planning poker.

Zmiany w Backlogu w trakcie trwania sprintu

Właścicielem Backlogu sprintu jest zespół deweloperski, i tylko on może wprowadzać w nim zmiany w trakcie trwania sprintu (przypis Scrum Guide, Przewodnik do Scrumie, s14).

Backlog prezentuje informacje o stanie danego sprintu, dlatego jest on na bieżąco aktualizowany w trakcie sprintu – dodawane są np. informacje o tym, do kogo dane zadanie zostało przydzielone, i jaki jest jego status realizacji.

Dopuszczalne są zmiany w samych zadaniach, więc jeżeli zespół uzna, że w trakcie planowania sprintu nie zostały uwzględnione wszystkie niezbędne zadania, albo że zadania zostały błędnie sformułowane – wówczas może on wprowadzić odpowiednie zmiany do backloga sprintu, po czym kontynuować pracę zgodnie z nowymi ustaleniami[6].

Możliwe jest również edycja backloga polegające na usuwaniu zadań niepotrzebnych, czy też zmiany dotyczące oszacowanej pracochłonności.

Szczególym przykładem zmiany wprowadzanej w backlogu sprintu to zmiany w samym zakresie sprintu, a więc np. usuwanie z niego zadań, czy historyjek, jeśli zespół uzna, że nie będzie w stanie ich wykonać w ramach danego sprintu. Tego typu zmiany powinny jednak być ustalane drogą negocjacji z Product Ownerem[7].

Bibliografia

Przypisy

  1. Mastelarz M. (2015) Zwinne podejście w zarządzaniu przedsiębiorstwem "Zeszyty Naukowe Uniwersytetu Szczecińskiego", nr 863, s. 82
  2. Sachdeva S. (2016). Scrum Methodology, "International Journal Of Engineering And Computer Science", nr 5, s. 16798
  3. Sachdeva S. (2016). Scrum Methodology, "International Journal Of Engineering And Computer Science", nr 5, s. 16798
  4. Chrapko M. Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice 2015, s. 252
  5. Chrapko M. Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice 2015, s. 258
  6. Chrapko M. Scrum. O zwinnym zarządzaniu projektami wydanie II rozszerzone, Wydawnictwo Helion, Gliwice 2015, s. 257
  7. Schwaber K. (2013) Scrum Guide, Przewodnik do Scrumie: Reguły gry, s. 10

Autor: Karolina Zasada