W Scrum’ie jest jedno miejsce, gdzie są widoczne wszystkie wymagania odnośnie rozwoju produktu. Ta lista zadań nigdy nie jest kompletna, a dodatkowo zmienia się z tygodnia na tydzień. Na szczęście to jest źródło przyszłych zadań a nie aktualnych.
Podstawy
Na temat Product Backlog można pisać bez końca, ot chociażby we Wrześniu wyszła aktualizacja publikacji Scrum.org, Evidence-Based Management Guide EBM, która wskazuje jak na bieżąco korygować plan, aby zbudować największą wartość. W tym artykule skupię się tylko na podstawowych kwestiach.
Product Backlog posiada cechy:
- Jest jeden dla jednego Produktu, nawet jeżeli pracuje wiele zespołów nad jednym produktem.
- Posiada jedną osobę odpowiedzialną za to: Product Owner
- Jest to uporządkowana lista zadań względem wielu czynników
- O kolejności decyduje PO, i każdy respektuje jego decyzje
- Jest ciągle rozwijany
- Dopóki Produkt istnieje – istnieje Product Backlog, nawet po ostatecznym produkcyjnym uruchomieniu.
Product Backlog Refinement – doskonalenie
W trakcie prac Zespół Deweloperski spotyka się razem z Właścicielem Produktu aby wspólnie omówić przyszłe zadania. Elementy Backlogu są dyskutowane i wyjaśniane. Programiści w trakcie takiego spotkania powinni zadawać doszczegóławiające pytania, tworzyć subtaski.
Product Owner jest zobowiązany do tego, aby każdy dobrze rozumiał omawiane zadania, w kocu jego głównym celem jest maksymalizacja pracy Zespołu Deweloperskiego.
Infografika
Przykładowa grafika prezentująca realny stan Product Backlog.
Podsumowanie
Nie ma innego źródła zmian w produkcie. Dodatkowo tylko PO może ustalać priorytety. Takie sztywne reguły chronią aktualny plan i wizję produktu. Ani CEO, ani PM nie są uprawnieni do ręcznej zmiany priorytetów zadań oraz tworzenia wrzutek. Każdy element Product Backlog musi zostać omówiony i oszacowany przez Zespół Deweloperski – i dopiero wtedy może zostać podjęty do realizacji.