Moim zdaniem najtrudniejsza rola w zespole Scrum’a. Właściciel Produktu jest osobą odpowiedzialną za to, aby Zespół Deweloperski pracował najwydajniej. Ma ku temu narzędzia i uprawnienia które mu na to pozwalają
Definicje
Product Backlog – lista zadańzwiązana z tworzonym produktem, nigdy nie jest skończona, jest ustalana na bieżąco. Tutaj rządzi PO.
Sprint Backlog – wybrane element z Product Backlog (te najlepiej opisane na górze listy) wraz z planem realizacji w trakcie Sprintu. Tutaj rządzi Zespół Deweloperski.
W artykule opisuje relację PO i Product Backlog.
Co robi PO?
W większości jest to uszczegółowianie zadań, tak aby Dev Team dokładnie rozumiał to co powinien zrobić. Oznacza to, że na górze Backlogu powinny widnieć zadania wystarczająco dobrze opisane, aby zespół mógł podjąć zobowiązanie do realizacji.
Kolejność zadań jest ustalana wraz z klientem – dzięki temu jest ustalany priorytet względem największej wartości dla klienta. Czasem może się wydawać, że kolejność jest “losowa” lub błędna względem technicznego rozwoju aplikacji – niestety w tej sytuacji najwazniejsza jest korzyśc i wartosc dla klienta.
Maksymalizacja wartości produktu
Dzięki temu, że kolejność zadań jest ustalana względem największej wartości dla klienta, zespół pracując skupia się na nich. Czasem są ważne kwestie do realizacji, lecz są odkładane z miesiąca na miesiąc, np.: poprawki wizualne które każdy chciałby zrobić – lecz jeżeli dla klienta nie jest to tak ważne na inne funkcjonalności – to niestety – PO ma obowiązek zmienić priorytety.
Dodam więcej – Product Backlog należy tylko do Właściciela Produktu i ma on pełne prawo do zmiany porządku, anulowania lub tworzenia nowych. To co wcześniej było gotowe do realizacji – teraz może być na samym koncu.
Takie podejście sprawia, że Zespół Deweloperski może się skupić nad realizacją aktualnego Sprintu, bez zmiany kontekstu i rozmyślania – co będzie w przyszłości. Dopiero jak dochodzi do planowania, zadania z góry backlogu są przenoszone do Sprintu.
Czego nie robi PO?
Zakazane dla PO aktywności.
- Zmiana aktualnego Sprintu
- Naciskanie na zespół do realizacji nieopisanych zadań
- Wywieranie presji na poszczególne osoby zespołu w celu innej implementacji niż opisana
- Zmiany wymagań bez konsultacji
- Anulowanie Sprintu bez konsultacji
- „Chowanie” zadań w trakcie sprintu aby pokazać je na planowaniu.
Podsumowanie
Bycie Product Ownerem to naprawdę trudne zajęcie, wiele osób myśli, że jest to lepszy Project Manager, lecz niestety nie – to zupełnie inny zakres obowiązków i kompetencji. O ile zespół deweloperski jest zawsze szczęśliwy w Scrum’ie, o tyle PO czasem może odczuwać dyskomfort ponieważ jego plany nie zawsze są realizowane z wielu powodów, głównym jest brak możliwości planów w trakcie jednego sprinta. W kolejnych artykułach opiszę te rolę dokładniej.