Checklista udanego doskonalenia backlogu

Doskonalenie Backlogu (Backlog Refinement, czy dawniej: Pielęgnacja Backlogu, Backlog Grooming) – jakkolwiek będziemy nazywać tę czynność, jej cel jest jeden: jest dopracowanie szczegółów kolejnych wymagań oraz ich oszacowanie i uporządkowanie.

Dobrze przeprowadzone sesje doskonalenia wymagań w pozytywny sposób wpływają na planowanie Sprintu. Stają się one szybkie i łatwe, ponieważ mamy już przygotowane pewne elementy, które są zdekomponowane i ułożone wedle priorytetów.

 

Pamiętajmy, że nie jest to jednorazowa czynność, tylko ciągły proces. Proces, który najczęściej przybiera formę osobnego spotkania.

W GetResponse bardzo dużą wagę przywiązujemy do doskonalenia Backlogu. Z tego względu, z czasem stworzyliśmy specjalną “checklistę”, która przede wszystkim ma stanowić pewien pretekst do oceny spotkania przez Scrum Mastera oraz wsparcia go w autorefleksji nad tym konkretnym obszarem. Jednocześnie pomaga nam ocenić, jak czynność ta wypada w poszczególnych zespołach, jakie zagadnienia wymagają poprawy i co można ulepszyć.

I właśnie dziś tą checklistą chcielibyśmy się z Wami podzielić. Ponieważ w GetResponse doskonalenie ma formę spotkań (najczęściej sumarycznie: 1 – 1.5h w tygodniu), stąd poruszane zagadnienia dotyczą takiej formy realizacji założeń ulepszania, pracy nad wymaganiami.

 

Forma i cel spotkania

• Jak często i w jakiej formie odbywa się doskonalenie? Ad hoc? Regularnie? Ile czasu sprintu zajmuje? Za dużo? Za mało?
• Kto w nim uczestniczy? Tylko Zespół Scrumowy? Czy wszyscy deweloperzy? Czy w razie potrzeby zapraszani są eksperci domenowi?
• Czy wszyscy uczestnicy spotkania faktycznie są na nim potrzebni? Czy nie ma osób, które się nudzą?
• Czy Product Owner wie, jaki cel chce osiągnąć? Czy ten cel jest jasno komunikowany?

 

Przygotowanie do spotkania

• Czy przed doskonaleniem wszyscy wiedzą, jakie zagadnienia/wymagania będą omawiane, tak aby zdążyć się przygotować?
• Czy uczestnicy przychodzą przygotowani na spotkanie?

 

Jakość wymagań

• Jakie i jakiej jakości wymagania trafiają na doskonalenie?
• Czy są one znane zespołowi (np. z wcześniejszej zapowiedzi lub z backlogu) czy są dla niego całkowitą nowością (np. powstały tuż przed spotkaniem)?
• Czy były już wcześniej chociaż pokrótce wspomniane/zapowiedziane?
• Czy wymaganie jest rozpisane starannie i rzetelnie?
• Czy – jeśli na doskonalenie nie trafia wymaganie, ale po prostu pomysł, ogólna wizja – to czy jest dobrze przygotowana do omawiania? Czy Product Owner wie, z czego dana wizja wynika i co chce osiągnąć?
• Jak wymaganie jest przedstawiane na pielęgnacji?

 

Zachowanie uczestników na spotkaniu

• Jaką postawę prezentuje Product Owner?
  • Czy odpowiada na wszelkie pytania lub jasno komunikuje kiedy odpowie na te, na
    które w danej chwili nie zna odpowiedzi?
  • Czy tłumaczy Zespołowi Deweloperskiemu, dlaczego podejmowane są takie, a nie
  • inne decyzje?
  • Czy dopuszcza Zespół Deweloperski do współtworzenia wymagania?
  • Czy wysłuchuje i rozumie techniczne aspekty wymagań poruszane przez
    deweloperów?
• Jaką postawę prezentuje Zespół Deweloperski? Jaką postawę przyjmują jego poszczególni członkowie?
  • Czy chcą aktywnie uczestniczyć w spotkaniu?
  • Czy są zaangażowani?
  • Czy zadają pytania?
  • Czy rozumieją spojrzenie biznesowe? Jeśli nie, czy próbują je zrozumieć?
  • Czy nie skupiają się jedynie na technicznych aspektach wymagania?
  • Czy dyskusja nie jest zdominowana przez jedną, dwie, trzy osoby?
  • Czy rozumieją cel tworzonej funkcjonalności?
  • Czy dyskutują między sobą o możliwych rozwiązaniach technicznych?
  • Czy Zespół Deweloperski chce współtworzyć wymaganie?
• Jak wygląda dyskusja nad wymaganiem? Czy faktycznie ma miejsce DYSKUSJA pomiędzy deweloperami a Product Ownerem?
• Jak są rozwiązywane sytuacje sporne? Z czego one wynikają?

 

Przebieg spotkania

• Czy spotkanie nie jest nudne?
• Co jest widoczne na ogólnodostępnym ekranie w czasie spotkania? Kto nim “zarządza”?
• Czy w czasie spotkania rozpoznawane są zależności od innych zespołów albo z innymi wymaganiami? Czy są one zapisywane?
• Kto i gdzie spisuje ustalenia?
• Jak na koniec spotkania wygląda wymaganie, nad którym trwały prace?
• Czy w czasie spotkania odbywa się też szacowanie? Jak wpływa na to obecność Product Ownera? Być może jego obecność nie jest wówczas niezbędna? Czy nie warto zostawić szacowania na koniec spotkania?

 

Efekty

• Co jest efektem spotkania? Porównaj je z kilkoma ostatnimi – czy zachodzi proces nauki, inspekcji i adaptacji?
• Czy stworzone wymagania spełniają Definition Of Ready?
• Czy stworzone wymagania zawierają wszelkie potrzebne pliki graficzne, makiety, teksty lub czy zostały zlecone prace, które mają je przygotować?
• Czy Product Owner jest zadowolony z przebiegu spotkań i ich efektów?
• Czy Zespół Deweloperski jest zadowolony z przebiegu spotkań i ich efektów?

Sądzimy, że warto raz na jakiś czas przyjrzeć się tym zagadnieniom, być może część z nich poruszyć na retrospektywie.

 

A na koniec kilka prostych rekomendacji od nas, o co warto zadbać, aby doskonalenie było udanym spotkaniem:

• przygotować plan spotkania, listę wymagań do omówienia i rozesłać ją odpowiednio wcześnie do uczestników,
• przygotowywać się (ten punkt dotyczy wszystkich – Product Owner musi wiedzieć, dlaczego dana funkcjonalność ma być realizowana. Zespół powinien zaś wcześniej przemyśleć, o co chce zapytać lub jaka wiedza ekspercka będzie mu potrzebna),
• omawiać problemy, a nie gotowe wymagania (wymagania powinny być doszczegóławiane w trakcie rozmów i generowania pomysłów),
• zaprosić ekspertów z danego obszaru – jeżeli dane wymaganie dotyczy tematu, w którym zespół nie czuje się zbyt pewnie,
• pogłębiać wiedzę dotyczącą rozwiązań w kodzie obszaru, który będzie omawiany,
• wspierać inicjatywę wśród deweloperów (nie tylko Product Owner proponuje tematy do omówienia),
• grupować tematycznie lub technicznie omawiane wymagania – każde może wymagać innych kompetencji oraz posiadać różnych interesariuszy,
• uświadamiać sobie i oznaczać zależności między wymaganiami,
• nie rezygnować z doskonalenia, bo są pilne zadania i zespół ma mało czasu,
• nie organizować spotkania dłuższego niż 1h, bo wtedy zmęczenie uczestników przełoży się na jakość doprecyzowywanych wymagań,
• szacować tylko wymagania, które są kompletne.