Backlog Refinement

[PaweuB]

Backlog Refinement - sesja doskonalenia Backlogu.

PART I

Opierając się o wiele źródeł, można stwierdzić, że Backlog Refinement to jedno z najważniejszych spotkań w SCRUMie. Jednak nie wszystkie źródła traktują to spotkanie w identyczny sposób. Część opisuje to spotkanie jako moment, w którym możliwe jest dopracowanie User Stories w przypadku gdy występuje dużo placeholdersów lub niepewności. Inne źródła mówią o tym procesie jak o narzędziu, które pozwala na utrzymanie Backlogu aktualnego (np. zmiana priorytetów). Jednak większość źródeł jest zgodna: to spotkanie jest często częściowo ignorowane lub występuje w nieregularnych odstępach czasu, prowadzone bez odpowiedniej agendy i przygotowania. Podsumowując - nie ma ono w takiej formie jakiegokolwiek sensu, zabiera czas.

Jednak gdyby się zastanowić nad tym co może dostarczyć dobrze przeprowadzony Backlog Refinement w trakcie Sprintu, okazuje się, że niesie to ze sobą korzyści zarówno dla Produktu jak i Zespołu Developerskiego.

Korzyści:

1. Ogólne:

• uporządkowany backlog - opisany (specyfikacja), oszacowany, spriorytetyzowany

2. Dla Produktu:

• lepsza priorytetyzacja zadań
• możliwość poznania zależności między zadaniami o ile takie występują

3. Dla Zespołu Developerskiego:

• poznanie sensu biznesowego danych Stories

---

PART II

Czym grozi brak refinementu (błędne koło backlog refinementu):

• brak uszczegółowienia zadań
• brak realizacji celu sprintu (odejście od realizacji celu sprintu na rzecz zadań, które mogły „wskoczyć”, nie koniecznie z dobrze dobranym priorytetem)
• co raz dłuższe rozmowy na retrospekcji (bo przecież chcemy robić lepiej/inaczej)
• POCZUCIE PEŁNEJ MOBILIZACJI - żeby udało się dowieźć cel sprintu… nie trzeba czuć mobilizacji do działania, wystarczy wiedzieć co się robi.
• CHĘĆ DZIAŁANIA - po pełnej mobilizacji do działania oraz poświęceniu czasu na „wgryzanie się” w pracę nie ma już czasu na dodatkowe spotkania (np. Refinement) oraz na zastanowienie się nad tym czy aby napewno nasz produkt dąży w dobrym kierunku.

W tym miejscu chciałbym zakończyć bardzo krótkie wprowadzenie w Backlog Refinement oraz w dalszej części dostosować „dojście” do refinementu w trakcie sprintu do realiów Code-Poets.

---

PART III

Biorąc pod uwagę aktualny workflow Code-Poets oraz SCRUMowe podejście do zarządzania projektami przy wytwarzaniu oprogramowania można w odniesieniu do wielu źródeł zaproponować poniższą ścieżkę dojścia do Backlog Refinementu.

Ogólny zbiór wymagań Produktu > Priorytetyzacja wymagań Produktu > Uszczegółowienie Backloga (Stories, Placeholders) > Sprint Planning > Sprint Execution > Backlog Refinement

Jak robić Backlog Refinement?

1. Kiedy?
   W trakcie sprintu, w ściśle określony dzień, o stałej godzinie.

2. Jak długo?
   Backlog Refinement powinien zabierać nie więcej jak 10% czasu trwania Sprintu.

3. Kto?
   W różnych źródłach proponowane są różne konfiguracje personalne do przeprowadzenia refinementu, np. praca w parach senior - junior dev, product owner - senior dev, product owner - architekt.

4. Jak?
   Tak aby Backlog był uporządkowany i spriorytetyzowany, tak aby spełnić cel sprintu

---

Code-Poets Workflow:
Powyższy opis jest zbiorem informacji pozyskanych z różnych źródeł internetowych. Aby w pełni móc korzystać ze wszystkich dobrodziejstw tego procesu, należy go dostosować do danej organizacji, specyfiki projektu/produktu.
W Code-Poets pomimo niezachowania zasady „organizowania” tego spotkania w wyznaczonym czasie, odbywa się to w sposób ciągły, tj. Continuous Backlog Refinement. Jest to bieżąca/codzienna praca nad Backlogiem. Jest to dobre podejście w projektach, które nie są w pełni wyspecyfikowane na etapie planowania lub bądź nastawione są na szybki rozwój produktu (np. Concent)