Product Backlogs i Sprint Backlogs – krótki przewodnik
Product Backlog składa się z uporządkowanej listy prac do wykonania w celu stworzenia, utrzymania i utrzymania produktu. Jest ona zarządzana przez Product Owner.
W tej konkretnej sytuacji Backlog Produktu jest podzielony na 3 oddzielne podczęści w “widoku tablicy” Asany (Backlog, +2Sprint, +1Sprint), aby pomóc Właścicielowi Produktu w wizualizacji ostatecznej listy w pełni opisanych i uszeregowanych pod względem priorytetów elementów pracy, które są gotowe do przedstawienia deweloperom podczas Planowania Sprintu.
Sprint Backlog zapewnia przegląd prac rozwojowych, które mają zostać wykonane przez Deweloperów podczas bieżącego sprintu. Jest on zarządzany przez Deweloperów. Tylko deweloperzy mogą “wyciągać” elementy pracy z Rejestru Produktu do Rejestru Sprintu i robią to TYLKO podczas każdego wydarzenia Planowania Sprintu.
Czego Właściciel Produktu powinien unikać?
>
- Dodawanie elementów pracy z Rejestru Produktu do Rejestru Sprintu poza Planowaniem Sprintu
- Zmienianie wymagań elementów pracy, które są już w bieżącym Backlogu Sprintu.
- Zmiana priorytetu elementów pracy, które są już w bieżącym Backlogu Sprintu.
.
Dlaczego jest to problem?
Planowanie Sprintu to coś więcej niż dodawanie elementów pracy do Backlogu Sprintu. Jest to proces, podczas którego programiści określają, co będzie Celem Sprintu i biorą odpowiedzialność za dostarczenie tego Celu Sprintu. Jeśli ktoś przekracza zakres lub opis elementów pracy z już zaplanowanego sprintu, ten ktoś niszczy cały proces rozwoju. W rezultacie programiści tracą czas z powodu przełączania kontekstu i nie są w stanie dostarczyć przyrostu produktu najwyższej jakości.
Wskazówki od Scrum Mastera
a) bądź zawsze przygotowany na planowanie sprintu i szanuj decyzje zespołu deweloperskiego;
b) jasno określ Cel Produktu i pomóż deweloperom zdefiniować następny Cel Sprintu;
c) opisywać elementy pracy dokładnie i jasno;
