Product Backlog Refinement czyli Doskonalenie Backlogu Produktu (dawniej Product Backlog Grooming) jest jednym z najbardziej tajemniczych elementów Scruma. Nie jest on wydarzeniem, więc nie znajdziemy go na liście Scrum eventów. Czym więc jest i dlaczego jest taki ważny dla każdego scrumowego projektu?
Doskonalenie Backlogu Produktu, czyli czego?
Nie można mówić o procesie Doskonalenia Backlogu Produktu bez zdefiniowania jak ten „doskonały” Product Backlog powinien wyglądać. I chociaż pisaliśmy już o nim wielokrotnie, zarówno definiując backlog, jak i wspominając o User Story. szacowaniu i Story Pointach, to prosta definicja ze Scrum Guide wydaje się wyjaśniać wszystko:
„Backlog Produktu to uporządkowana lista wszystkiego, co może być potrzebne w produkcie oraz jedyne źródło wymaganych zmian, które mają być w produkcie wprowadzone. Odpowiedzialnym za Backlog Produktu, w tym jego zawartość, dostępność i kolejność, jest Właściciel Produktu” – Scrum Guide
To właśnie nad tymi cechami backlogu pracuje Scrum Team w procesie doskonalenia. Czym jednak jest proces nazywany doskonaleniem? W jaki sposób je przeprowadzamy i dlaczego nie zostało ono ujęte w Scrum Guide jako wydarzenie?
Grooming vs Product Backlog Refinement
Zacznijmy od wyjaśnienia nazwy tegoż procesu. Przed rokiem 2013 proces, który jest tematem niniejszego postu, nazywał się Product Backlog Grooming. Słowo „grooming” było zaś tłumaczone na język polski jako „pielęgnowanie”. Zdaniem autorów Scruma, nie oddawało to dobrze idei tej czynności i prowadziło do nieporozumień. Dlatego też nie tak dawno temu nastąpiła zmiana na Product Backlog Refinement.
„Pielęgnowanie” sugeruje, że utrzymujemy coś w idealnym, uporządkowanym stanie. Gdy myślimy o pielęgnowaniu ogródka, to raczej do głowy nie przychodzi nam ciężka praca, ani czynność wymagająca dużo czasu. W ogródku też nie pojawiają się same z siebie nowe rośliny, ani nie zmieniają się priorytety.
Jak to zawsze lubimy powtarzać – backlog żyje i nigdy nie jest kompletny. W związku z czym nie możemy go jedynie utrzymywać (pielęgnować). „Grooming” został więc zastąpiony przez „refinement” czyli doskonalenie. To sugeruje, że dążymy do ideału, ulepszamy naszą listę wymagań, ale nigdy nie powiemy „to już wszystko, tak jest dobrze”.
Oczywiście nawyki trudno jest wyplenić i my też prowadząc szkolenia Scrum lubimy wtrącić historię o tym jak to „grooming” stał się „refinementem”. Bo chociaż w chwili pisania tego tekstu zmiana ma już ponad cztery lata, to i tak regularnie spotykamy się z nazwą „grooming”. Warto więc wiedzieć, co to jest.
Czym jest Product Backlog Refinement?
Doskonalenie Backlogu Produktu (ang. Product Backlog Refinement) ma na celu przygotowanie elementów znajdujących się na szczycie backlogu do realizacji w nadchodzących sprintach. Te wymagania mają, według Product Ownera, najwyższy priorytet i powinny być, w miarę możliwości, realizowane w pierwszej kolejności. Naturalne jest więc, że musimy wiedzieć co konkretnie jest tam do zrobienia.
„Doskonalenie (ang. refinement) Backlogu Produktu jest działaniem polegającym na dodawaniu szczegółów, oszacowań i porządkowaniu elementów Backlogu Produktu” – Scrum Guide
Mówiąc krótko, jeśli wiemy co jest do zrealizowania w danym wymaganiu i jesteśmy pewni, że mamy wszystkie potrzebne zasoby i środki, a także zdążymy wykonać tę pracę w jednym Sprincie, to nie musimy przeprowadzać refinementu dla tego elementu. Ale backlog nigdy nie zawiera tylko jednego wymagania i zawsze będą takie, w których mamy więcej pytań niż odpowiedzi.
Dlatego też Product Backlog Refinement jest procesem ciągłym. Scrum Team, włączając w to Product Ownera, może uszczegóławiać wymagania w każdej chwili w trakcie trwania sprintu. Nie ma znaczenia, czy rozmawiamy o elementach backlogu podczas dedykowanego spotkania, luźnej rozmowy na korytarzu czy lunchu.
Właśnie z tego powodu twórcy Scruma nie włączyli Product Backlog Refinementu do zestawu wydarzeń. Spotkanie to nie powinno być „sztywnym” wydarzeniem, podczas którego Scrum Team będzie siedział i rozwodził się nad wymaganiami. Backlog ma być ulepszany na bieżąco.
Doskonalenie, a wynik Sprintu
Nie od dziś wiadomo, że realizacja nowych lub gorzej rozpoznanych wymagań zajmie nam więcej czasu. Celem Product Backlog Refinementu jest przybliżenie Scrum Teamowi wiedzy o poszczególnych wymaganiach w taki sposób, aby ten rozpoczynając pracę nad jego realizacją miał już wiedzę pozwalającą na „wejście” w temat.
Praca naszego zespołu powinna rozpocząć się wraz z pierwszym „dzwonkiem” sygnalizującym rozpoczęcie nowego Sprintu. Jeśli zamiast za realizację zaplanowanych wymagań zabierzemy się za rozpaczliwe poszukiwanie odpowiedzi na pytanie „O CO W TYM CHODZI?”, nie oszukujmy się – nie zdążymy. A nawet jeśli, to jakim kosztem?
Posiadanie podstawowej wiedzy o wymaganiach powoduje, że elementy estymowane są dokładniej, bo wiemy co mniej-więcej jest do wykonania. Pośrednio wpływa to również na ilość wymagań spełniających DoD (Definition od Done), a więc na ilość dowiezionych funkcjonalności.
Definition of Ready
Niektóre zespoły mające problemy z ukończeniem zaplanowanej podczas spotkania Sprint Planning pracy nakładają na elementy Backlogu dodatkowe wymagania w postaci Definition of Ready. O „gotowości” wspomina również Scrum Guide, która w podręcznikowym rozumieniu uważana jest za wymaganie, które można ukończyć w pojedynczym Sprincie.
„Elementy Backlogu Produktu, które mogą zostać „Ukończone” przez Zespół Deweloperski w pojedynczym Sprincie, uznawane są za „Przygotowane” do rozważenia podczas Planowania Sprintu.” – Scrum Guide
Podręcznik zakłada, że skoro jesteśmy pewni, że dany element backlogu ukończymy w jednym Sprincie, to jest ono na tyle małe i na tyle dobrze rozpoznane, że nie ma tam żadnych niejasności. Czasami to jednak nie wystarcza. Dlatego możemy rozszerzyć kryterium gotowości do Definition of Ready.
Definition of Ready to nic innego jak zestaw kryteriów, które musi spełniać wymaganie aby mogło w ogóle być rozważane przez zespół podczas Sprint Planningu. Dodanie dodatkowego punktu kontrolnego na elementy Backlogu powoduje, że zespół bardziej szczegółowo analizuje wymagania i podejmuje w stosunku do niech właściwe działania.
Bo to właśnie zespół decyduje, czy wymaganie jest gotowe do realizacji. I chociaż czasami przejście do stanu gotowości oznacza dodatkową pracę, to warto odważyć się i wprowadzić te rozwiązanie do naszego projektu. Nawet jeśli początkowo będziemy mieli kłopot z dostępnością wymagań spełniających Definition of Ready. Stawką są przecież zrealizowane wymagania.
Czy warto inwestować czas zespołu?
Zgodnie z założeniami czas przeznaczony na Doskonalenie Backlogu Produktu to 10% czas trwania Sprintu. Zakładając, że zgodnie ze światowymi standardami Sprint trwa 2 tygodnie (80 godzin) czas przeznaczony na tę czynność powinien zamknąć się w 8 godzinach.
Te 8 godzin jest niewielkim nakładem w stosunku do spodziewanych korzyści. Największą z nich jest na pewno zdrowy backlog, niezbędny do uzyskania efektywnego Scruma. Nie musimy chyba opowiadać, co się dzieje, jeśli w ogóle nie przeprowadzamy sesji „refinementowych”.
To tyle, jeżeli chodzi Product Backlog Refinement, jego najważniejsze cechy i powody, dla których nie został ujęty w wydarzeniach Scrum. W jednym z kolejnych wpisów postaramy się wskazać na zagrożenia związane z utrzymywaniem Backlogu w stanie, delikatnie mówiąc, „nieaktualnym”. A jeśli potrzebujecie praktycznych porad jak przeprowadzić PBR, zapraszamy do komentarzy (poniżej) oraz dedykowanego filmu na YouTube.
Więcej o Product Backlog Refinement, a także innych aspektach metodyki Scrum możesz dowiedzieć się na naszych scrumowych szkoleniach.
wszystko jasne, mam pytanie o praktykę. Jak to w rzeczywistości wyglada. Wiem, mamy 10% czasu czyli te 8 godzin na sprint ale kiedy dokładnie i jak przeprowadza się doskonalenie ? Zaraz po daily siadamy z zespołem i omawiamy jakieś motywy ? Ile tematów na raz, jak długo takie spotkanie trwa i gdzie w sprincie jest to umiejscowione ? To musi być robione na bieżąco więc zakładam , że robie spotkanie po daily jak jest potrzeba np 2-3 razy w tygodniu ? Czy tego typu spotkania wrzucam tez do PB ?
Reasumując:
jak długie spotkania
kiedy one wsytępują przed czym/po czym
ile tematów na raz omawiać ? to ścieśle powiązane z pytaniem o długość spotkania.
czy cały zespół scrumowy jest na takim spotkaniu ?
Ponieważ nie jest to spotkanie, ale „proces ciągły”, to czasami będzie on dział się „w tle” (np. przyjdzie Product Owner i rzuci do zespołu, „słuchajcie wpadło mi takie, a takie wymaganie, czy to w ogóle jest do zrobienia?” z czego wywiązuje się krótka dyskusja), czasami będą to niezaplanowane spotkania (np. analityk czytając backlog napotka na jakiś problem, więc weźmie kilka osób do pomocy i spróbują go rozpracować), a czasami to będzie spotkanie wrzucone w kalendarz przez PO, SM lub kogoś z zespołu (np. „usiądźmy i upewnijmy się, że w przyszłym Sprincie będziemy mieli co robić”).
Nie ma jednego przewidzianego momentu na wystąpienie Product Backlog Refinementu. Najczęściej jest to kilka krótkich spotkań w trakcie Sprintu omawiających to, co jest do robienia w kolejnej iteracji. Chcemy się upewnić, że wszyscy wiedzą co jest do zrobienia i jak można to zrobić. Jeśli rozpracowujemy jeden duży temat, to pewnie skupimy się tylko na nim. Jeżeli mamy dziesięć małych zadań, to omówimy je wszystkie. Zwykle zespół sam wypracowuje sobie skuteczną formę.
Jeżeli nie wiemy jak zacząć – wrzućmy dwa spotkania tygodniowo po godzinę i dajmy sobie za cel „brak dyskusji na temat szczegółów wymagań na kolejnym Planowaniu Sprintu”. Upewnijmy się, że wszystkie wymagania są zrozumiałe i oszacowane przez wszystkich członków zespołu, a ich zrozumienie odpowiada wizji Product Ownera. Sprawdźmy czy kryteria akceptacji są na odpowiednim poziomie szczegółowości. Przypomnijmy sobie, czego nam brakowało na poprzednim planowaniu i co wyszło w trakcie Sprintu, a powinno być wiadome wcześniej.
W końcu dojdziemy do takiej wizji Refinementu, która jest praktyczna i daje korzyści całemu zespołowi.
Co do składu – najlepiej jest robić refinement pełnym składem, bo tylko w takim wypadku mamy szansę na dowiedzenie się o wszystkich zależnościach, ryzykach i szansach. Np. jedna osoba z zespołu już to kiedyś robiła, a bez niej będziemy wymyślać koło na nowo. Albo typowy przykład, gdzie okazuje się, że testowanie funkcjonalności jest o wiele cięższe niż samo jej zrobienie, co ma zasadniczy wpływ na jego wycenę.
dziekuję Tomasz, zastanawiało mnie czy wrzucać na tablicę bo to jednak trochę czasu schodzi i warto to uwzględnić w pracach. Traktuje to jak szacowanie wymagań niefunkcjonanych, które potrzebują konkretnej ilości pracy.
Na pewno nie wrzucałbym tego do backlogu. Co do umieszczania na tablicy – jeżeli w pracach uczestniczą wszyscy członkowie zespołu, to taka informacja też niewiele nam da, bo u każdego będzie widniało to samo (brak wartości dodanej). Jak już, to pomyślałbym nad jakąś wizualizacją stanu backlogu na przyszły Sprint (ile jeszcze refinementu potrzebujemy).
ok ale piszesz:
„Jeżeli nie wiemy jak zacząć – wrzućmy dwa spotkania tygodniowo po godzinę i dajmy sobie za cel “brak dyskusji na temat szczegółów wymagań na kolejnym Planowaniu Sprintu””
to mamy zostać po godzinach pracy i to omawiać ? Czy robić to kosztem pracy bierzącej ?
To na sprint 8 godzin pracy wychodzi – jeden dzień pracy znika a to ma wpływ na efekt końcowy ?
Chodzi mi o to gdzie w którym momencie uwzględnia się ten czas. Czy zespół dev ma w głowie tą czynność i po prostu pomniejsza ilość historyjek, która wciąga na sprint ?
Co w przypadku mocno rozbudowanego produktu z dużą ilością niewiadomych, może te 8 godzin być za mało gdy się okazuje, że musimy zaplanować nie 1 a 3-4 sprinty do przodu dlatego się zastanawiam czy nie wrzucać tego do PB
Ok, odpowiadając po kolei:
„to mamy zostać po godzinach pracy i to omawiać ?”
Oczywiście, że Product Backlog Refinement jest wykonywany w ramach bieżącej pracy. To po prostu jeden z obowiązków.
„Chodzi mi o to gdzie w którym momencie uwzględnia się ten czas. Czy zespół dev ma w głowie tą czynność i po prostu pomniejsza ilość historyjek, która wciąga na sprint ?”
Jeżeli Zespół Scrumowy nie robił wcześniej refinementu, to oczywiście w momencie w którym zacznie go robić, te 8 godzin przestanie być poświęcane na dewelopment. Teoria (i praktyka) głosi, że zwróci się to w postaci lepiej przygotowanych wymagań, a na pewno w przypadkach gdy wykryjemy potencjalne wtopy zanim weźmiemy się do pracy.
Jeżeli Zespół Scrumowy robi PBR w każdym Sprincie, to Velocity na podstawie którego zespoły się planują, już uwzględnia ten „koszt”.
„Co w przypadku mocno rozbudowanego produktu z dużą ilością niewiadomych, może te 8 godzin być za mało gdy się okazuje, że musimy zaplanować nie 1 a 3-4 sprinty do przodu”
Na pewno PBR nie powinien zajmować więcej niż te 8 godzin. Jeżeli potrzebujemy aż tyle czasu, to trzeba kopnąć Product Ownera, żeby rozpoznał temat, a nie przychodził z niewiadomymi.
Chciałbym też zwrócić uwagę na jedną rzecz. Piszesz o „produkcie z dużą ilością niewiadomych”. W takiej sytuacji tym bardziej nie ma sensu planować się na „3-4 Sprinty do przodu”, bo te niewiadome spowodują, że już po pierwszym Sprincie cały ten plan pójdzie w łeb.