Estimating the Product Backlog – Szacowanie Rejestru Produktu

Szacowanie rejestru produktu (ang. Estimating the Product Backlog) to moment, w którym okresowo Zespół Scrum będzie szacował wielkość każdej pozycji z rejestru produktu.
Przed planowaniem wydania i okresowo, w miarę jak Product Backlog rozwija się a zespół uzyskuje zrozumienie przez doświadczenie, Zespół Scrum będzie szacował wielkość pozycji w Product Backlogu. Jest to kluczowa informacja, która ma pomóc Właścicielowi Produktu w podjęciu decyzji dotyczących priorytezacji poszczególnych pozycji w rejestrze produktu. Niektóre pozycje mogą stać się mniej priorytetowe, jeżeli Właściciel Produktu dowie się, że ich dostarczenie będzie wymagało większego wysiłku.
Szacunki są względne oraz są mierzone w „punktach” a nie rzeczywistych jednostkach wysiłku. Na początku może to wydawać się nieprzewidywalnym, ale po pierwszych kilku sprintach Zespół Scrum może empiryczne wyprowadzić szybkość, która pozwala im na dokładne przewidzenie zdolności do dostarczenia.
Szacowanie elementów rejestru produktu pozwala na ogólne określenie ich rozmiaru i ilości pracy niezbędnej do włożenia w ich przygotowanie. Jest to pomocne z dwóch powodów: pomaga w ustalaniu priorytetów oraz pozwala śledzić i prognozować postęp projektu.
Zauważ, że w procesie Scrum istnieją dwa odrębne szacunki: ogólne w rejestrze produktu, wskazujące przybliżony rozmiar elementu, a także szczegółowe w rejestrze sprintu, opisujące rozmiar zadania, zwykle podawane w godzinach.”[2]
Najczęściej stosowaną metodą szacowania pozycji rejestru produktu są punkty. Punkty to miara ogólna i relatywna, dotycząca włożonego wysiłku i rozmiaru danego elementu.
Mariusz Charpko w [4 proponuje:
Są dwa podejścia:
1) Z puli dostępnych historyjek wybieramy jedną, najmniejszą, i przyznajemy jej 1 punkt. Szacowanie każdej kolejnej historyjki odbywa się przez porównanie jej do historyjki jednopunktowej.
2)  Ustalamy skalę, najlepiej od 1 do 10. Następnie spośród dostępnych historyjek wybieramy średnią i przyznajemy jej 5 punktów. Dalej postępujemy dokładnie tak jak w punkcie pierwszym. Szacujemy historyjki przez porównanie ich do historyjki pięciopunktowej.
Użycie miary relatywnej pozwala na dostosowanie jej niemal do każdego rodzaju projektu. Co więcej, przybliża zespołowi deweloperskiemu poszczególne pozycje rejestru produktu, gdyż wymaga zastanowienia się nad każdą jego pozycją.

Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.

Podobne wpisy
Krok 3 – Uszczegółowienie procesu biznesowego

To działanie polega na uszczegółowieniu wybranych procesów biznesowych. Celem tego działania jest: identyfikacja wszystkie ról, produktów, zdarzeń w organizacji, a więcej

Krok 2 – Identyfikacja procesów biznesowych

Działanie to polega na identyfikacji procesów biznesowych znajdujących się w modelowanym obszarze organizacji. Celem tego działania jest: identyfikacja procesów biznesowych więcej

Krok 1 – Szacowanie potrzeb organizacji

To działanie polega na ustalaniu celów modelowania procesów biznesowych. Celem tego działania jest: określenie obszarów, które będą modelowane, ustalenie zakresu więcej

Zwinne modelowanie procesów biznesowych w trzech krokach

Zwinne (Agile) modelowanie procesów biznesowych, w moim odczuciu, musi zawierać minimum trzy zasadnicze kroki: Krok 1 - Szacowanie potrzeb organizacji więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top