Priorytetyzacja zadań w backlogu. Case z perspektywy Product Ownera

Product Owner to rola w procesie scrumowym. Jest odpowiedzialny za biznesowy aspekt projektu i/lub produktu.

Wiedza o tym, jak ustalać priorytety pracy wpływa na powodzenie projektu, zaangażowanie zespołu i rolę lidera. Wszystkie projekty, zwłaszcza duże, złożone, wymagają jasnych priorytetów. Łatwiej powiedzieć, niż zrobić, prawda? Zwłaszcza gdy każde zadanie wydaje się być priorytetem numer jeden i wymaga uwagi.

Jakiś czas temu mój zespół dokonywał przeglądu procesu Agile i zastanawiał się nad przejściem ze sprintów na styl Kanban. Zadaliśmy sobie wtedy pytanie, na jakim poziomie właściciel produktu powinien ustalać priorytety? Czy na poziomie Feature, czy Epic czy Story? 

Priorytety w backlogu produktu

Proces Projektowania Rozwiązania

User story

Powszechnie wiadomo, że programiści pracują na poziomie user story. Mogą również pracować na poziomie zadania, ale najwyższym punktem jest historia. Oznacza to, że właściciel produktu (PO, product owner) przesyła i nadaje priorytet story oraz bugs (błędom).

Możliwe jest, aby jedna story została podzielona na wiele historii z powodu planowania, podziału pracy miedzy różnych programistów. W takim przypadku product owner może być zdezorientowany pojawieniem się „ różnych” historii.

Epic

To zbiór pracy podzielony na konkretne zadania nazwane user stories i tworzony na podstawie potrzeb klientów lub użytkowników).

Feature (Funkcjonalność):

Alternatywnie moglibyśmy pozwolić właścicielowi produktu pracować na poziomie funkcji, pozwalając programistom na kontynuowanie pracy z historiami użytkowników. Oznacza to, że PO przesyła i nadaje priorytet funkcjonalnościom.

Problem z tym podejściem polega na obsłudze błędów. Ponieważ błędy pojawiają się na poziomie historii użytkownika.

Projektowanie na przykładzie

Doszliśmy do wniosku, że Product Owner jest osobą patrząca z szerszej perspektywy i powinien stawiać na Epiki. Następnie powinien zejść do poziomu Story. Wtedy, w zależności od funkcjonalności, zaczynają pojawiać się priorytety dla user stories. Spróbuje zobrazować to przykładem. Załóżmy, że budujemy zakładkę „Aktualności” na stronie www.

Możemy mieć następujące epiki:

1. Pisanie aktualności
2. Komentowanie aktualności
3. Udostępnianie aktualności

Najpierw trzeba popracować nad pierwszą epiką, czyli napisaniem aktualności ponieważ nie można komentować ani udostępniać czegoś, co nie istnieje. Właściciel produktu musi zdecydować, która z pozostałych dwóch epik jest ważniejsza: komentowanie czy udostępnianie.

Po podjęciu decyzji Właściciel Produktu jest na takim etapie:

1. Pisanie aktualności
2. Udostępnianie aktualności
3. Komentowanie aktualności

Udostępnianie aktualności jest ważniejsze. Co jest wymagane, aby to wszystko zrobić? Podział na historie.

1. Pisanie aktualności:

a. Dodaj nową aktualność.

b. Zaktualizuj istniejącą aktualność.

c. Usuń aktualność.

d. Pokaż aktualność.

2. Udostępnianie aktualności:

a. Udostępnij na stronie.

b. Udostępnij w social media.

c. Udostępnij przez e-mail.

3. Komentowanie aktualności:

a. Dodaj komentarz.

b. Oznacz komentarz jako nadużycie.

c. Usuń komentarz.

d. Moderuj komentarz.

Ustalanie priorytetów w backlogu produktu

Jeśli skupimy się na pierwszej epice: „napisz aktualność” mamy cztery historie, priorytet tych historii zaczyna być jasny. Nie możesz przeglądać, aktualizować ani usuwać czegoś, dopóki nie zostanie to utworzone, więc dodanie nowej aktualności jest numerem jeden. Wyświetlanie, aktualizowanie i usuwanie jest drugiej w kolejności.

Ustalanie priorytetów odbywa się na dwóch poziomach:

– epik – żeby zobaczy szerszy obraz,

– historii użytkowników.

Na poziomie Story zaczynasz dostrzegać zależności między historiami. Pomaga to w ustalaniu priorytetów historii dla zespołu programistów. Ponadto, ustalenie priorytetów na poziomie historyjek użytkownika pozwala właścicielowi produktu uzyskać niektóre istotne części Feature znacznie wcześniej, niż pozostałe — może jednocześnie przeglądać wiele funkcji.

Właściciele produktu nie powinni nadawać priorytetu zadaniom dołączonym do historyjek użytkownika, ponieważ zadania są tworzone i należą do zespołów programistycznych wykonujących pracę i to oni najlepiej wiedzą, co należy zrobić i jak to zrobić, aby dostarczyć historyjkę użytkownika.

Oczywiście zaproponowany sposób wynika z moich doświadczeń w pracy w zespole scrum, niekoniecznie jest to oficjalnie uzgodniony sposób realizacji 😊 

Bibliografia: Jeff Sutherland: Scrum. Czyli jak robić dwa raz więcej, dwa razy szybciej.