Czy cała praca, którą musi wykonać Development Team musi ostatecznie pochodzić z Product Backlogu? Jak interpretować w tym kontekście zadania, które dodaje zespół do Sprint Backlogu?
Odpowiedzi (2)
Zaloguj się, aby móc oceniać, komentować, odpowiadać...
-
2
W Product Backlogu (PB) rejestrowane są wymagania do zrealizowania/zaimplementowania w Przyroście (rozwiązaniu) i raczej unika się wprowadzania tam zadań/tasków czyli "pracy do wykonania". Te identyfikowane są dopiero na początku Sprintu (lub czasie trwania).
Scrum odróżnia wymagania zapisywane w PB od "pracy" czyli zadań, które są częścią Sprint Backlogu.
Zespół Deweloperski (ZD) (opłacany przez PO) nie powinien pracować nad czymkolwiek innym, aniżeli wymaganiami z PB->Sprint Backlogu i wynikającymi z nich zadaniami.
Dodanie do Sprint Backlogu:
- Jeżeli ZD chciałby dodać jakieś wymaganie do Sprint Backlogu (bieżący Sprint), to powinien uzyskać zgodę/aprobatę PO.
- Jeżeli ZD zidentyfikuje dodatkowe zadanie (pracę) niezbędne do zaimplementowania jakiegoś wymagania ze Sprint Backlogu, to nie musi uzyskiwać na to zgody PO.
-
0
Tak, cała praca dla Deweloperów powinna pochodzić z jednego źródła, tj. z transparentnego, uporządkowanego Product Backlogu.
Deweloperzy (Od 2020 roku nie ma już roli o nazwie "Zespół Developerski", a są po prostu Developerzy) na Planowaniu Sprintu wspólnie z PO określają Cel Sprintu i na tej podstawie dobierają odpowiednie elementy Product Backlogu niezbędne do jej zrealizowania i tworzą Sprint Backlog.
Sprint Backlogiem zarządzają Deweloperzy. W trakcie Sprintu mogą do niego wedle uznania dodawać, usuwać, zmieniać zadania, ale warunkiem jest osiągnięcie Celu. Rzadko kiedy na Planowaniu Sprintu udaje się przewidzieć 100% wszystkich zadań i podzadań także jest to normalne zjawisko i praktyka pozwalająca zachować elastyczność i dostosować się do pojawiających się zmian :)
Odnośnie dzielenia elementów Backlogu czy konkretnie Historyjek Użytkownika, to polecam lekturę wpisu na blogu Agile Adept: Jak dzielić user story.
