Backlog sprintu
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).
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[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ó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[7].
Przypisy
Backlog sprintu — artykuły polecane |
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 |
Bibliografia
- Chrapko M. (2015), Scrum: o zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice
- 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