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

 

Cały cykl artykułów na temat metodyki Scrum jest pod adresem: https://www.michalwolski.pl/tag/metodyka-scrum/ . Zapraszam do lektury.

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.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close