Według mnie najważniejszym artefaktem Product Ownera, czy Product Managera pracującego ze zwinnym zespołem scrumowym jest Product Backlog. Z doświadczenia wiem, jak łatwo go zaniedbać i doprowadzić do nieporządku, oraz jak trudno odpowiednio ułożyć proces współpracy z zespołem, dotyczący min. dodawania nowych elementów Backlogu, by nie stracić kontroli nad tym, co się w nim dzieje.

W tym artykule dowiesz się czym jest Product Backlog, co oznacza proces jego pielęgnacji, czym są sesje pielęgnacyjne oraz znajdziesz kilka wskazówek, które warto zastosować w praktyce aby utrzymać porządek w organizacji pracy z Backlogiem.

Co na temat Product Backlogu mówi Scrum Guide?

Poniżej znajdziesz najważniejsze punkty, esencję tego co Scrum Guide mówi o tym artefakcie.

  • Cały zespół może realizować zadania związane z zarządzaniem Product Backlogiem (min. dodawaniem nowych zadań, aktualizacją opisów, jego pielęgnacją). Jednak to Product Owner jest ostatecznie za niego odpowiedzialny i priorytetyzuje jego zawartość, tak aby osiągać postawione cele. Kolejność i zakres zadań w Product Backlogu odzwierciedla decyzje Product Ownera jeżeli chodzi o priorytet realizowanych zadań. Nikt nie może zmusić zespołu do pracy poza kolejnością wyznaczoną przez Product Ownera w Backlogu.
  • Product Owner musi mieć pewność, że cały zespół rozumie zawartość poszczególnych elementów backlogu.
  • Scrum Master wspiera Product Ownera w znajdowaniu odpowiednich technik i metod do efektywnego zarządzania Product Backlogiem. Upewnia się, że Product Owner wie jak odpowiednio priorytetyzować zadania, aby maksymalizować wartość dostarczaną przez zespół oraz, że cały zespół rozumie zawartość poszczególnych elementów backlogu.
  • To zespół decyduje o tym ile elementów Backlogu wejdzie do kolejnego Sprintu. Podczas spotkania planistycznego Zespół Scrumowy wyznacza cele, które chce dowieść w kolejnej iteracji (czego odzwierciedleniem są zadania wybrane do stworzenia konkretnego przyrostu produktu)
  • Podczas Przeglądu Sprintu (z ang. Review meeting), gdy zespół zaprezentuje efekty poprzedniego Sprintu i zbierze feedback od interesariuszy, Product Backlog jest aktualizowany.
  • Product Backlog to uporządkowana lista wszystkiego co może być zrobione w produkcie, tj. nowe funkcje, wymagania, błędy do naprawienia, optymalizacje. Elementy Backlogu mają swój opis, estymaty oraz są uporządkowane wg kolejności.
  • Pielęgnacja Backlogu (z ang Product Backlog refinement) oznacza proces, dzięki któremu do poszczególnych elementów Backlogu regularnie dodawane są szczegółowe opisy, estymacje, a także ustalany jest ich priorytet. Proces ten ustala indywidualnie Product Owner z Zespołem i współpracują, aby wspólnie aktualizować Product Backlog.
  • Elementy Backlogu, które są położone wysoko na liście (tj. mają nadany wysoki priorytet przez Product Ownera) przeważnie są opisane bardziej szczegółowo niż te, które mają niższy priorytet i czekają na swoją kolej.

Co więc oznacza Pielęgnacja Backlogu?

Jest to proces, który służy temu, aby Product Backlog był aktualny, a jego elementy dobrze opisane, a także oszacowane przez zespół. Rozkładanie historyjek na czynniki pierwsze, dyskusja nad nimi, a także oszacowanie przez zespół, daje Product Ownerowi więcej informacji do tego, aby świadomie nadać im odpowiedni priorytet.

Wspólna praca na Product Backlogiem sprawia również, że zespół dobrze wie, czym jest produkt, jakie są nadchodzące wyzwania, oraz czego dotyczą zadania o najwyższym priorytecie, które wpadną do zespołu w ramach kolejnej iteracji.

Pracę nad Backlogiem Produktu ułatwia zespołowi także odpowiedni podział elementów na Epiki (realizowane inicjatywy), oraz odpowiednie etykietowanie/tagowanie zadań, które ułatwia wyszukiwanie i organizację pracy w Backlogu podczas spotkań takich jak Planowanie, czy Przeglądu Sprintu.

Czy za dodawanie, precyzowanie oraz dzielenie zadań na mniejsze zawsze odpowiada Product Owner? U nas w SentiOne świetnie sprawdziło się wdrożenie roli “feature leadera” – do każdego większego projektu/inicjatywy już na poziomie Roadmapy Produktu przypisywany był programista, wspierający Product Managera, również w tworzeniu nowych zadań lub ich doprecyzowaniu. Dzięki temu zespół czuje się współodpowiedzialny za wytwarzany produkt, a także za Product Backlog, w ramach którego organizują swoją pracę.

Source: Atlassian Documentation

Sesje pielęgnacyjne

Najczęściej w firmach pracujących zwinnie, najważniejszym elementem procesu pielęgnacji Backlogu są regularne spotkania Product Ownera z zespołem, nazywane sesjami pielęgnacyjnymi, groomingami, czy też refinementami.

Przykładowo, raz w tygodniu zespół ma zaplanowane w kalendarzu godzinne spotkanie z PO, gdzie przechodzą przez nowe elementy Backlogu, które wymagają doprecyzowania i estymacji. Product Owner powinien być zawsze przygotowany do tego spotkania – do omówienia nowych zadań, czy błędów, których jest zawsze więcej niż czasu na oszacowanie, dlatego już przed tym spotkaniem selekcjonuje elementy, aby zespół mógł skupić się na tym, co najważniejsze. W trakcie spotkania może się również z dyskusji okazać, że trzeba dodać nowe zadania do Backlogu, lub zaktualizować stare.

Jeśli chodzi o dobre praktyki, to często pojawia się pytanie “jak często organizować takie spotkanie” i “ile czasu powinno trwać”, tutaj dobrze się sprawdza taktyka – częściej, a krócej (czyli lepiej zrobić co tydzień co godzina, niż raz na dwa tygodnie przez 2-godziny).

Dobre praktyki związane z Product Backlogiem w firmach.

Poniżej kilka wskazówek od Product Managerów dla tych, którzy dopiero rozpoczynają swoją pracę z Backlogiem Produktu. Wskazówki zostały pozyskane w dwóch kanałach:
1. Grupa na facebooku Product Management PL
2. Grupa na facebooku Agile3M

Oto i one:

1. “Kto w Waszych firmach dodaje zadania do Backlogu?”: Wszyscy. Bardzo mocno edukujemy Developerów/QA żeby też dodawali zadania, chcemy mocno uniknąć “PM to dodaje taski”.

2. Dla Juniora najważniejsze – jak najszybciej zgromadzić sobie przynajmniej 1-2 zgroomowane sprinty (w zaleznosci od dlugosci) do przodu na wszelki wypadek, dobre tagowanie/labelkowanie/releasowanie ticketów żeby się nie pogubić.

3. Błędy do Backlogu najczęściej dodają deweloperzy i testerzy, no chyba, że pochodzą z zewnętrznego feedbacku. Przeważnie zespół jest na tyle samoorganizujący się, że wydaje sugestię kiedy powinniśmy fixować to, co dodali, a czasami potrzeba priorytetyzacji.

4. Mamy też taki “event”, który nazywa się bugbash – dobieramy wtedy 1-2 testerów z zewnątrz projektu i wszyscy siadamy na godzinę szukając bugów.

Bugi te wpisujemy do specjalnego sheeta, który po całym evencie jest “obrabiany”, weryfikowany i priorytetyzowany przez QA (do zaakceptowania priorytetów przez PM) i importowany przez PM’a do Jiry (mass import).

5. Z mojej osobistej perspektywy największym “wyzwaniem” jest domykanie zadania od razu po wprowadzeniu do Jiry. Zdarza się, że coś wpada “znienacka” i między spotkaniami brakuje czasu aby je dokładniej opisać. Kończy się to tym, że po jakimś czasie ulatuje kontekst problemu i traci się sporo czasu na wracanie do takiego ticketu. Nie jest to oczywiście żadna szczególna “praktyka”, ale akurat tego staram się ostatnio bardzo mocno pilnować 🙂 Dobry, szczegółowy opis wraz z kontekstem problemu to podstawa.

6. Co jakiś czas kasować dolną 1/4 backlogu. Zwykle są tam rzeczy których i tak nigdy nie zrobimy (kołdra jest niemal zawsze za krótka), więc po co utrudniać sobie życie?

7. Alternatywnie, raz na pół roku automatycznie kasować wszystkie te elementy backlogu, w których tym okresie nic się nie zadziało (nie było komentarzy, nie zmieniał się priorytet, opis).

Chciałbyś dodać wskazówkę od siebie w tematyce Product Backlogu lub jego pielęgnacji? Zostaw komentarz lub napisz do mnie na priv: [email protected].

➔ Skorzystaj z oferty naszych kursów online: Kurs projektowania modeli biznesowych, Kurs Product Ownera.

Dołącz do naszych czytelników

Dołącz do 1 700+ subskrybentów otrzymujących nasz cotygodniowy newsletter z inspiracjami do tworzenia coraz lepszych produktów i rozwoju swojej kariery.
Olga Springer
Head of Product w SentiOne. Związana z zarządzaniem produktami informatycznymi od początku kariery zawodowej. Zorientowana na skalowanie firmy i zwinny rozwój produktu. W SentiOne odpowiada za Roadmapę produktu i kluczowe projekty dla biznesu. Certyfikowany Professional Scrum Master i Prince2 Practitioner.

2 KOMENTARZE

  1. Cześć,

    przyznam się, że przez opis teorii trochę przeleciałem (bo wydawało mi się to oczywiste), ale naprawdę dużo wartości znalazłem w radach od innych PO z pola walki ❤ bardzo dobrze się czytało, dziękuję 😊

    dobrego dnia

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.