Product Backlog Refinement – zgodny ze sztuką

book

Wiedza | PROCES

Product Backlog Refinement to proces porządkowania i uaktualniania Backlogu Produktu.

Każdy kontener używany do przechowywania czegoś wymaga od czasu do czasu sprzątania. Czy to garaż, czy szafka na dokumenty. Jeżeli ciągle coś do niego dodajemy bez jednoczesnego porządkowania, to szybko robi się bałagan i trudno cokolwiek w nim znaleźć. Jednak garaż różni się znacznie od szafki na dokumenty, bo przechowujemy w nich bardzo różne rzeczy. Tak też Backlog Produktu tworzonego przez 3-osobowy zespół w startupie, bardzo różni się od Backlogu Produktu używanego przez 10 zespołów w korporacji. Ciągły proces utrzymywania go w porządku (tak zwany Product Backlog Refinement) też będzie więc inny.

 

Porządek w Backlogu Produktu jest ważny, ponieważ kiedy go nie ma, to:

  • Product Backlog zaczyna rosnąć. Nie wyrzucimy niepotrzebnych już elementów, bo ich już dawno nie rozumiemy, a skoro ich nie rozumiemy, to nie wiemy, czy są potrzebne. Zresztą zawsze mogą się przydać, pracę ktoś włożył w ich napisanie…
  • Elementy Product Backlogu (PBIs) zaczynają się powtarzać, bo łatwiej jest dodać coś nowego niż sprawdzić, czy to coś już jest.
  • Product Backlog zaczyna się mnożyć. Jak nie rozumiem tego “głównego”, to zrobię sobie swój, bo gdzieś chcę mieć zapisane, co jest do zrobienia. Oczywiście, każdy nowy zawiera coś trochę innego, a jak lista np. bugów jest dla mnie ważna, to lepiej trzymać ją oddzielnie, żeby się nie zgubiła tym bałaganie.

W efekcie, kiedy programista nie wie, w jaki sposób coś zrobić, to zapyta kogoś (opcja optymistyczna) lub coś wymyśli, aby tylko nie spędzać 10, 15, 30 minut na szukaniu odpowiedzi w tym bałaganie.

 

Problem tworzenia oprogramowania jest problemem wielokrotnie złożonym. Brak porządku w Backlogu Produktu zwykle spycha go na granice chaosu, który nie sprzyja produktywności.

Product Backlog Refinement

Proces Product Backlog Refinementu, czyli cykliczne czyszczenie i uaktualnianie Backlogu Produktu, daje nam jedno, jasne i przejrzyste źródło wiedzy o tym, co jest do zrobienia w ramach produktu.

 

Tylko skąd wiemy że mamy dobry Product Backlog Refinement?

  • Gdy zmienią się jakieś decyzje, to ktoś natychmiast wpada na pomysł, że wpisze to do Product Backlogu.
  • Gdy Zespół Deweloperski czegoś nie pamięta, to odruchowo zagląda do Product Backlogu.
  • Gdy Product Owner czegoś nie pamięta, to w pierwszej kolejności zagląda do Product Backlogu.
  • Gdy interesariusze czegoś nie wiedzą, to zaglądają do Product Backlogu.

 

Wszyscy w to samo miejsce. A robią tak, ponieważ tam są informacje podane w jasny i przejrzysty sposób.

 

A co konkretnie się dzieje w czasie Product Backlog Refinementu?

Product Owner spotyka się regularnie z Zespołem Deweloperskim, żeby:

  • przedyskutować, co w ramach dużych przedsięwzięć warto zrobić najpierw i wydzielają te zadania do osobnych PBI,
  • podzielić duże zadania na mniejsze,
  • ustalić szczegóły PBI, które planują zrobić w najbliższym czasie,
  • dodać/zmieniać estymację zadań,
  • przedyskutować wartość biznesową PB i ustalić priorytety,
  • często zdarza w toku prac usunąć niepotrzebne już PBI, co jest bardzo ważnym elementem utrzymania porządku.

 

Jeżeli do przedyskutowanie powyższych tematów potrzebni są interesariusze, architekci lub inne mądre głowy, to należy je zaprosić. Scrum Guide nie pisze wprost że mają być, nie pisze też że nie wolno ich zapraszać. Scrum jest fremeworkiem, daje ramy – tutaj ramą jest cel: Produkt Owner z Zespołem Deweloperskim mają uporządkować backlog i przygotować go na planowanie. W jak to zrobią i z czyjej pomocy skorzystają Scrum Guide nie wnika.

 

No to czemu nie jest to po prostu jedno z wydarzeń w Scrumie?

 

Product Backlog Refinement nie jest wydarzeniem, ponieważ nie każdy zespół musi spotykać się w tym celu raz na Sprint, czy w jakikolwiek inny narzucony z góry sposób. Moi klienci najczęściej mają Refinementy:

  • raz na dwutygodniowy Sprint,
  • dwa razy na dwutygodniowy Sprint,
  • raz na tygodniowy Sprint,
  • jak PO uzna, że trzeba to ustalają kiedy się spotkają.

 

Jeżeli u Was jest potrzeba częściej, rzadziej, inaczej to tak właśnie powinniście robić. Ważne aby nie zajmowało to zbyt wiele czasu. Scrum Guide zaleca nie więcej niż 10% czasu.Szczegóły techniczne nie powinny pochłaniać spotkania. W centrum ma być Wasza strategia na dostarczanie wartości klientom.

Powiązane artykuły, mogą Cię też zainteresować!

7 sposobów na jeszcze skuteczniejsze Sprint Review

Celem Sprint Review jest zebranie wartościowego feedbacku, który da nowe spojrzenie na produkt. Poniżej kilka sposobów j...

Czy warto suszyć i całować Product Backlog?

Każda osoba w zespole deweloperskim podejmuje codziennie dziesiątki decyzji. Mogę one wspierać wizję Product Ownera i je...

Prosty przepis na udany produkt

Jesteś głową organizacji. Chcesz tworzyć świetne produkty. Scrum wydaje się rozsądnym wyborem. Przepis wydaje się pro...

Sprint Review - zgodne ze sztuką

Celem Sprint Review JEST uzyskanie feedbacku od interesariuszy o Inkremencie i zaplanowanie dalszego rozwoju produktu.