Backlog sprintu

Backlog sprintu
Polecane artykuły
Planowanie sprintu Estymacja czasu trwania zadań Sprint review Sprint Zarządzanie zakresem Etapu Feature-Driven Development User stories Kamień milowy Zarządzanie integralnością wg PMBOK

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.

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

• 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).

TL;DR

Backlog sprintu to lista zadań wybranych z backlogu produktu, które są realizowane w trakcie sprintu w metodyce SCRUM. Etapy tworzenia backlogu sprintu obejmują wybór historyjek użytkownika, podział na zadania i szacowanie czasu ich wykonania. Zmiany w backlogu mogą być wprowadzane w trakcie sprintu przez zespół deweloperski.

Etapy tworzenia Backlogu sprintu

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

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:

• 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.

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

Szczególnym 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.

Bibliografia

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

Autor: Karolina Zasada