Checklista udanego doskonalenia backlogu

4 min
Zaktualizowano:

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.

 

Kilka wskazówek na koniec

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.

 

 

Share