Blog

Czym jest Refinement?

Backlog Refinement (zwany także Pielęgnacją Backlogu lub coraz rzadziej groomingiem) jest pracą wykonywaną nad Backlogiem Produktu. W jej efekcie Backlog z każdą iteracją zawiera coraz lepiej przygotowane elementy (wymagania, historyjki itd.), które są zdekomponowane i wyszacowane, ze zidentyfikowanymi zależnościami, a także wspólnie zrozumiane na odpowiednim poziomie (im wyższa pozycja elementu na Backlogu, tym więcej detali). Dzięki temu górna część Backlogu zawiera wymagania zdekomponowane i opisane w takiej formie, że Zespół Developerski może je zmieścić w Sprincie. Reszta Backlogu zawiera tym mniej detali, im schodzimy niżej na liście, ale wciąż wiadomo, że znajdują się tam rzeczy wartościowe dla rozwoju produktu w bliskim horyzoncie czasowym i Zespół Scrumowy potrafi wyjaśnić dlaczego.

Kiedy odbywa się Refinement?

W Scrumie Refinement nie jest osobnym zdarzeniem, a raczej ciągłym procesem dbania o kształt Backlogu, zadawania odpowiednich pytań i wyjaśniania nieścisłości – dlatego nałożony jest na niego przydatny timebox: nie więcej niż 10% długości Sprintu. W skalowaniu z użyciem Nexusa timebox znika – to zespoły mają same zdecydować, w jaki sposób i ile będą poświęcać pielęgnacji, biorąc pod uwagę współzależności i poziom niepewności reprezentowany przez obecne elementy Backlogu Produktu.

Znane mi zespoły korzystają oczywiście z pielęgnacji *ad hoc*, ale zazwyczaj starają się zarezerwować w swoich kalendarzach czas na spotkanie się i wspólną dyskusję. Bardziej efektywne jest poświęcanie godziny dziennie niż skomasowanie 6-8 godzin w jednym dniu.

Czemu służy Refinement?

Refinement nie zastępuje Planowania Sprintu. Nie służy zaplanowaniu pracy, nie ma na celu zbudowania planu implementacji wymagań w Sprincie ani tym bardziej „scope’u” na kilka sprintów do przodu. Dostarcza za to poszerzonej wiedzy o tym, co czeka Zespół Developerski w perspektywie całego backlogu (z pełną świadomością, że Backlog żyje cały czas i wiele wymagań może ulec znacznej modyfikacji, dodaniu lub usunięciu) oraz pogłębionej – w perspektywie 2-3 najbliższych sprintów (również z założeniem, że uwarunkowania biznesowe mogą wywrócić to do góry nogami najpóźniej tuż przed rozpoczęciem Planowania Sprintu). Przy dobrze wypielęgnowanym Backlogu, Planowanie idzie sprawniej, bo Zespół wie co i po co będzie robić, jest mniej zaskakiwany wymaganiami, widząc zbliżającą się niewiadomą może wykonać tzw. spike (krótki eksperyment, służący eksploracji możliwych opcji rozwiązania), jak również jest w stanie wcześniej identyfikować różne zależności – zarówno te między elementami Backlogu, jak i wynikające z zewnętrznych uwarunkowań organizacji.

Kto bierze udział w Refinemencie?

W Refinemencie bierze udział najczęściej Product Owner i Zespół Developerski (i Scrum Master, czyli Zespół Scrumowy), chociaż pielęgnowanie może również odbywać się bez udziału Product Ownera lub przy obecności tylko niektórych członków Zespołu. Zależy to od poziomu omawianych detali i tematów. Mogą w nim brać udział także zaproszeni interesariusze lub zewnętrzni eksperci, jeśli mogą udzielić odpowiedzi na pytania Zespołu (chociaż ciekawy argument przeciwko temu wystosował Mike Cohn – uważa, że grozi to zbyt szczegółowym wchodzeniem w detale „jak coś będzie działać” i z tego powodu limituje obecność tylko do Zespołu Scrumowego).

Jak przebiega Refinement?

Nie istnieje uniwersalna recepta na przeprowadzenie pielęgnacji, ale dobrym pomysłem jest rozpoczęcie przygotowań od zastanowienia się, co będzie się działo przed, w trakcie i po sesji pielęgnacyjnej.

Przed Refinementem

• Product Owner powinien omówić z interesariuszami aktualny Backlog Produktu, zebrać uwagi i jeśli uzna je za stosowne, odłożyć je na nim w formie wymagań (nawet zgrubnych). Backlog jest zasilany nowymi wymaganiami w czasie Przeglądu Sprintu, ale także w ramach innych interakcji na linii PO-interesariusze.
• Szczególnie ważnym jest, by zadbać o to, czy pomysły interesariuszy wpisują się w cel i wizję produktu oraz czy naprawdę przynoszą w nim wartość. Tylko takie warto odnotować na Backlogu.
• Product Owner nie musi samodzielnie zapisywać wymagań, nie musi też na razie dbać o format ich zapisu (np. User Stories itp.), ale musi zdecydować o ich pozycji (kolejności) na Backlogu.

W trakcie Refinementu

• Product Owner prezentuje Zespołowi Backlog w aktualnym kształcie.
• Poczynając od góry, wymagania są omawiane i doprecyzowane.
• Jeśli Zespół rozumie w wymaganiu „co?” oraz „dlaczego?”, to przechodzimy dalej.
• Ważne, żeby dyskusja nad każdym elementem Backlogu miała timebox (np. 15 minut)
• Wymagania, które nie są sensowne biznesowo albo ich wartość jest za mała względem włożonego wysiłku, Product Owner powinien zrzucać z Backlogu.
• Wymagania, które pozostają na Backlogu, mają dopisywane kryteria akceptacyjne.
• Zespół szacuje złożoność wymagań (obojętną techniką: No Estimates, Planning Poker, Affinity Estimation, rozmiary koszulek itd.). Nawet stwierdzenie „duże, średnie, wystarczająco małe” jest formą szacunku pracochłonności.
• Jeśli zachodzi potrzeba, to wymagania są dekomponowane przez Zespół na mniej złożone (ale wciąż sensowe biznesowo i wertykalne, tj. idące wskroś warstw technologicznych, a nie w poprzek).
• Jeśli istnieje umówiony format zapisu, np. w formie User Stories, to te wymagania, które jest sens tak zapisać, zostają przeformułowane. Nie warto robić tego jednak na siłę, np. dla wymagań niefunkcjonalnych lepszym zapisem będzie Given-When-Then.
• Jeśli wymaganie jest zrozumiane, zapisane, opisane, ma odpowiednią pozycję na Backlogu, kryteria akceptacji, przypisany szacunek pracochłonności, jest zdekomponowane na wystarczająco małe i możliwie niezależne od innych, to można uznać, że jest ono na tyle wypielęgnowane, by można je było w przyszłości wziąć do Sprintu.
• Te wymagania, które na razie są średnie lub duże, ale mają mniejszą wartość biznesową, będą ułożone na niższych pozycjach w Backlogu Produktu.
• Refinement kończy się gdy omówione zostaną wszystkie elementy Backlogu Produktu lub gdy skończy się przewidziany czas na spotkanie.

Po Refinemencie

• Jeśli nadal nie omówiono całego Backlogu, nie wykorzystano 10% długości Sprintu lub gdy istnieje wyjątkowa potrzeba, to umawia się kolejną sesję pielęgnacji Backlogu.
• Góra Backlogu ma być na tyle wypielęgnowana, że można ją wziąć do pracy na Planowaniu Sprintu nawet w razie nieobecności Product Ownera – choroby, urlopu. Kolejność elementów na Backlogu jest tożsama z wolą Product Ownera co do kolejności ich realizacji.
• Jeśli istnieje potrzeba wykonania spike’a, to trzeba zadbać, by:
  • był on normalną pracą, odłożoną na Backlogu Produktu,
  • posiadał ścisły timebox, cel i oczekiwania,
  • był odpowiedzią na pytanie, zebraniem informacji albo prostym eksperymentem potwierdzającym sensowność biznesową lub technologiczną, ale jeszcze nie działającym elementem produktu.

Znaczenie Refinementu

Dzięki pielęgnowaniu Backlogu Produktu, Zespół Developerski i Product Owner pogłębiają swoje zrozumienie budowanego produktu (od strony biznesowej i technicznej), jak i wzajemną współpracę.

Planowanie Sprintu może więc lepiej służyć zbudowaniu przez Zespół planu implementacji wymagań wziętych do Sprintu, zamiast dopiero odkrywaniu, co też się kryje za poszczególnymi elementami Backlogu.

Dobrze wykonany Refinement pomaga uchwycić zależności w produkcie, zapewnić, że istnieje wspólne zrozumienie sensu budowania przyrostu, jak również otwiera przestrzeń do szerokiego dyskutowania o sposobach osiągania celów biznesowych.