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
Sprint Retrospective – Retrospekcja Sprintu

Retrospekcja Sprintu (ang. Sprint Retrospective) jest głównym mechanizmem pozwalającym na uzyskanie informacji zwrotnej na temat kondycji procesu scrum. "Retrospekcja sprintu pozwala więcej

Sprint Review – Przegląd Sprintu

Każdy sprint kończy się Spotkaniem Przeglądowym Sprintu (ang. Sprint Review Meeting), gdzie zespół prezentuje potencjalnie wykonalne przyrosty produktu. Na końcu każdego więcej

Release Planning – Planowanie Wydania

Planowanie wydania (ang. Release Planning) to czas, w którym na początku projektu zespół utworzy wysokiego poziomu plan realizacji produktu. Na więcej

Sprint Planning Meeting – Planowanie Sprintu

Na spotkaniu dot. Planowania Sprintu (ang. Sprint Planning Meeting) Zespół Scrum oraz Właściciel Produktu określają, które cechy i zadania będą więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry