Product Backlog i pojęcie pielęgnacji Backlogu

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.

➔ Product Management Academy (8.10 - 26.11) ✨ - 7-tygodniowy program warsztatów z product managementu

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).

8. Mi bardzo pomogół nieprzekraczalny limit itemów w backlogu – 50. W limit nie wchodzą taski, które zespół sobie wrzuci (say osobny task do designu, backendu, analityki, itp). Jeżeli coś jest tylko pomysłem, idzie do trello na listę pomysłów do rozważenia. Taki limit pomaga też rozróżnić bugi tolerowalne i te, które serio trzeba naprawić. 50 to horyzont wykonalności, reszta to pobożne życzenia. Ważne jest również być jedynym ownerem i tak pisać tytuły zadań/bugów/researchu by na 1szy rzut oka było zrozumiałe o co chodzi w danym wpisie.

9. Korzystam z epik, gdzie grupuje sobie działania. Dodatkowo dla zadań, które maja dalszy termin realizacji stosuje zbiorczy task pod tytułem: Wymagania klienta XX i wyceniam go np. na 2000 story pointów (w miarę realna wartość musi być, aby znać horyzont czasowy realizacji). Dzięki temu kolejkuję sobie tak duże projekty, a tylko bieżące działania maja duży poziom szczegółowości przez co dużo zadań – uszczegóławiamy to sobie na refinementach.

10. Wywal z backlogu wszystko, czego realizacji narazie nie jesteś w stanie sobie wyobrazić w najbliższym horyzoncie czasu. O ile możesz, bo za takim potężnym backlogiem w dużych firmach idzie to dziwne poczucie spokoju interesariuszy, że przecież „coś jest na backlogu”. Jako jedne z 300, ale jest, więc jest dobrze

11. Mi się sprawdziło grupowanie w odpowiednie etykiety i epici w zależności od klienta / inicjatywy. Dąże aby epic był zamykalny (widać i znać koniec) zaś etykiety stosujemy na rzeczy utrzymaniowe i ciągle powracające. W odpowiednich filtrach możemy sobie grupować i wyświetlać rzeczy interesujace. W backlogu nadal jest bardzo dużo życzeniowych tematów, ale przy odpowiednim procesie na refinemencie i dbaniu i każde wypełnione pole, daje radę uzyskać przejrzystość. *Do mojego backlogu wgląd ma sporo interesariuszy, dlatego każdy tam dorzuca swoje życzenia.

12. Jeśli korzystacie z Jirki to możesz ustawić rule, np. jeśli issue w backlogu siedzi +30 dni bez zmiany statusu to trafia do iceboxa, a po kolejnych 30 jest zamknięte jako won’t do.

13. Najbardziej użyteczne wskazówki to według mnie:

– codzienna praca z backlogiem (niby oczywiste, ale rzadko praktykowane) – zarezerwuj sobie 30-60 min czasu codziennie i przeglądaj po kolei itemy. Zadawaj pytania, wyjaśniaj, doprecyzowuj, cancelluj to, co niepotrzebne

– regularnie, np. raz na sprint, raz w miesiącu organizuj długie sesje pracy z backlogiem (pół dnia lub dzień) – to jest czas, kiedy możesz pracować z całymi epikami

– priorytetyzuj – won’t have i could have z modelu moscow niemalże z automatu do zamknięcia

Nie ma złotej reguły porządkowania backlogu. Jeśli chcesz mieć go uporządkowany, to musisz włożyć w to sporo pracy.

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].