Product Backlog
Backlog, albo też Product Backlog to zbiór zadań, który czeka na zespół w bliżej nieokreślonej perspektywie.
Każde z tych zadań przedstawione jest jako historyjka użytkownika, ze zdefiniowanymi kryteriami akceptacji. Co to oznacza? Oznacza to tyle, że każde z tych zadań jest opisane tak, że zespół wie co ma zrobić.
Product Backlog możemy sobie wyobrazić jako worek z zadaniami, ułożonymi zgodnie z priorytetami. Sprowadza się to do tego, że kiedy byśmy do Backlogu nie sięgnęli, to na szczycie listy będzie zawsze to zadanie, które powinno być zrobione jako pierwsze. Co z kolei oznacza, że jak zespół potrzebuje pracy to zerka do Backlogu i bierze pierwsze zadanie.
Kto ustala priorytety Backlogu?
Product Owner. Tak przynajmniej nakazuje Scrum. Natomiast często dzieje się to po dyskusji z zespołem. Chodzi o to, żeby osoba ustalająca te priorytety miała świadomość jaki potencjalny koszt będzie mieć dane zadanie (Estymowanie). W połączeniu z potrzebami klienta i uzgodnionymi terminami, Product Owner będzie mieć lepszą świadomość jak szybko praca nad danym zadaniem ma być zaczęta.
Kiedy zespół bierze zadania z Backlogu?
Kiedy tego potrzebuje. Ale zgodnie ze Scrumem zagląda się do Backlogu podczas Sprint Planningu. To jest ten moment kiedy bieżący cykl pracy się kończy. Tym cyklem pracy jest 2 tygodniowa iteracja, czyli tzw. sprint. Koniec sprintu oznacza, że zespół dostarczył bieżące zadania i jest gotów, żeby zacząć pracę nad nowymi.
„Jesteśmy organami rozrodczymi świata maszyn” – Marshall McLuhan
„Jesteśmy jedynie środkiem do czegoś dalece bardziej doskonałego” – Ryszard Blak
Ile zadań brać do sprintu?
Tyle ile jest w stanie przerobić. Ale skąd mamy to widzieć? Każde zadanie, czyli historyjka użytkownika (User Story), jest wyceniona w punktach. Historycznie wiemy, ile w ostatnich iteracja takich punktów łącznie udało się zrealizować. Na tej podstawie możemy wyliczyć średnią, która posłuży jako limit punktów dla planowanego sprintu.
Estymowanie
Zespół w czasie odrębnego spotkania omówił to zadanie i określił jego złożoność/trudność w skali 1-21 punktów, tzw. Story Pointów. Nie wszystkich liczb się używa, bo bo dostępne punkty brane są z ciągu Fibonacciego.
Ile to jest 1 Story Point?
Tyle ile trzeba. A tak na poważnie, to nie ma jednolitej zasady, bo raczej nie robi się bezpośredniej konwersji z punktów na godziny. Jest pewną praktyką przyjmowanie jakichś założeń, np.. że 1 Story Point to 1-4 h itd. Kiedy zadanie sięga wyższych wartości, trzeba podzielić na mniejsze kawałki łatwiejsze do przetrawienia.
Powiązane wpisy:
- Czym jest Velocity
- Jak pisać User Story
- Czym jest Capacity zespołu
- Co to jest Product Backlog w IT
- Jak pisać User Story
- Czy to wszystko mit? – czyli jak na prawdę pracuje się w IT
- Humanista pośród informatyków
Dodaj komentarz