Udoskonalanie backlogu: 30-minutowy runbook (i to, co nigdy nie powinno się w nim wydarzyć)

„Porządkowanie backlogu” lub „udoskonalanie zaległości” to spotkanie, które większość zespołów pomija w połowie; nie ma dla niego ceremonii Scrum Guide, wartość jest trudna do wyczucia w tej chwili, a słabo prowadzony ma wrażenie 90 minut kłótni o opisy zadań. Ten post to element Runbook: do czego właściwie służy udoskonalanie, 30-minutowa wersja, która działa, dwa antywzorce, które ją psują, oraz to, co nigdy nie powinno się wydarzyć podczas spotkania udoskonalającego.

Do czego naprawdę służy doprecyzowanie backlogu

Trzy konkretne wyjścia. Jeśli twoje udoskonalenie tego nie przyniesie, oznacza to, że organizujesz niewłaściwe spotkanie.

1. Zadania blisko szczytu zaległości mają opisy przyszłości, którą ty (lub członek drużyny) możesz poznać na zimno.
The kryteria akceptacji jest zapisane w zgłoszeniu. Zakres pracy jest zapisany w zgłoszeniu. Uzasadnienie też się w nim znajduje, nawet jeśli to jedno zdanie. Bez tego planowanie sprintu zmienia się w pytanie „co właściwie oznacza to zgłoszenie?”.

2. zadania mają mniej więcej wymiary.
Nie każdy zadanie tak ma punkty historii jeszcze. Ale zgłoszenia, które prawdopodobnie trafią do następnego lub kolejnego sprintu, powinny mieć oszacowanie, choćby przybliżone. Bez oszacowań planowanie sprintu staje się spotkaniem poświęconym szacowaniu i trwa 90 minut. Estymator punktów fabularnych pomaga, gdy zespół się nie zgadza.

3. Zbyt duże historie są podzielone.
Historia 13+ dostrzeżona w wyrafinowaniu to dużo taniej podzielić niż tę samą historyjkę zauważoną dopiero podczas planowania. Wtedy trzeba dzielić ją pod presją czasu, gdy cały zespół czeka. Podczas dopracowywania backlogu można ją spokojnie przemyśleć. Rozdzielacz historii daje Ci osiem wzorów do wyboru.

To wszystko. Trzy wyjścia. Opis jakości, rozmiaru, podziału.

Wersja 30-minutowa

Dla zespołu 4–7 inżynierów pracującego w dwutygodniowych sprintach harmonogram wygląda tak: spotkanie w połowie sprintu, w rytmie tygodniowym — raz w tygodniu bez planowania, z pominięciem tygodnia, w którym odbywa się planowanie.

00:00 - 00:03  | Quick context; what's in the next sprint shape?
00:03 - 00:18  | Walk top 5-8 backlog items
                  • Lead reads ticket title + acceptance criteria
                  • Anyone on team flags missing detail or risk
                  • Estimate (or "needs spike")
                  • Move to next
00:18 - 00:25  | Splits and spikes
                  • For each story flagged 13+ or "unclear"
                  • Either propose a split now or create a 1-pt spike
00:25 - 00:30  | Backlog tidy
                  • Bump priority of recently-blocked items
                  • Mark dead tickets as cancelled (don't quietly carry them)

Razem: 30 minut. Powtarzające się co tydzień. Jedna osoba ułatwia (zwykle prowadzi). Obracaj z biegiem czasu.

Najważniejsza zasada: doprecyzowanie wymagań nie jest projektowaniem implementacji

To właśnie tę zasadę zespoły łamią najczęściej. Dlatego większość spotkań doprecyzowujących trwa 90 minut.

Podczas doprecyzowania właściwe pytanie dla każdego zadania brzmi: „Czy rozumiemy, jak wygląda ukończone zadanie, i czy jest ono wystarczająco małe?”

Błędne pytanie brzmi: „Jak technicznie to zbudujemy?”

Rozmowa „jak” należy do fazy wdrożenia, po zaplanowaniu, kiedy inżynier wybierający zadanie jest sam na sam z bazą kodu. 6-osobowy zespół stojący i debatujący „czy powinniśmy zastosować metodę ankietowania, czy wypchnąć webhook” przez 20 minut, marnuje 2 godziny czasu inżynieryjnego na sprint, na decyzję, którą powinien podjąć ten, kto odbierze zadanie.

Tania heurystyka: jeśli rozmowa przenosi się na konkretną nazwę klasy, wybór biblioteki lub „Myślę, że powinniśmy użyć wzorca X”, zatrzymaj się i oznacz ją w celu uzyskania dalszych informacji. Wyrafinowanie to nie miejsce. Pójść dalej.

Antywzorzec 1: cichy zrzut zaległości

Objaw: Lead dodawał zgłoszenia przez cały tydzień. Udoskonalenie to pierwszy raz, kiedy zespół je widzi. Inżynierowie wpatrują się w nieznane zgłoszenia, prowadzący je czyta, pyta „jakiekolwiek pytania?”, a zespół, nie mając kontekstu, odpowiada „nie”.

Skutek: zadania są stemplowane bez kontroli. Dwa tygodnie później na etapie planowania połowa z nich okazuje się niejednoznaczna, przewymiarowana lub błędna.

Poprawka: zgłoszenia są dodawane do zaległości przez cały sprint, a lider zespołu zapisuje jednowierszowy opis i kryteria akceptacji podczas tworzenia zgłoszenia. Każdy ma dostęp do backlogu i może skanować w ciągu tygodnia. Udoskonalenie jest sprawdź, a nie recenzja pierwszego przejścia.

Jeśli Twój zespół naprawdę nie ma czasu na śledzenie zaległości asynchronicznych, nie masz problemu z udoskonaleniem; masz problem z posiadaniem zaległości. Lider przejmuje myślenie zespołu, zamiast je rozdzielać.

Antywzorzec 2: dyskusja otwarta

Objaw: Zgłoszenie powoduje 20-minutową dyskusję. Trzy osoby mają odmienne zdanie. Facylitator pozwala mu działać, ponieważ „ważne jest, aby się dostosować”.

Rezultat: dopracowanie dobiega końca, zespół się męczy, a kolejne 4 zadania zostają opieczętowane, bo nikt nie ma już energii.

Poprawka: 5-minutowy limit na zadanie. Jeśli zgłoszenie wymaga więcej niż 5 minut dyskusji w celu udoskonalenia, nie jest poprawiane; jest zablokowany, a prawidłowa odpowiedź to jedna z:

• „To wymaga kolec. Utwórz zgłoszenie o wartości 1 pkt: „zbadaj X, zaproponuj podejście”.
• "To jest za duże. Podziel to: wrócę do następnego udoskonalenia z sub-zadaniami. "
• "To wymaga wyjaśnienia od klienta/PM. Oznaczenie go spowoduje ponowną wizytę. "

To wszystko legalne wyniki udoskonalenia. „Kłóciliśmy się o to przez 20 minut” nie jest.

Co NIGDY nie powinno się zdarzyć w udoskonalaniu

Krótka lista, której nauczyłem się na własnej skórze:

1. Pisanie zadań na żywo. Jeżeli zgłoszenie jest na tyle niejasne, że należy je przepisać na spotkaniu, spotkanie zostaje na nim zatrzymane; lead przejmuje odpowiedzialność; odwiedź ponownie w przyszłym tygodniu.
2. Szacowanie zadań, nad którymi nikt w zespole nie będzie pracował. Jeśli jest to zadanie frontendowy i tylko jeden inżynier zajmuje się frontendem, nie każ mu oceniać 5 osób. Zapytaj prywatnie inżyniera frontendu; schwytać; pójść dalej.
3. Zespół już oszacował ponowne rozpatrzenie mandatów. Gdy liczba jest włączona, pozostaje, chyba że coś istotnego się zmieni (zakres, zależność, wymagania).
4. Dodawanie zadań podczas wyrafinowanie. Nowe zadania trafiają do zaległości. Zostaną udoskonalone w przyszłym tygodniu, nie teraz.
5. Mówimy o biletach oddalonych o ponad 5 sprintów. Dopracuj wartość kolejnych 2 sprintów. Dalsze działania będą zmarnowanym wysiłkiem, ponieważ priorytety ulegną zmianie.

A co z zespołami Kanban?

Kanban Zespoły nie organizują ceremonii sprintu, ale istnieje ta sama potrzeba: zadania znajdujące się na szczycie zaległości muszą być gotowe do odbioru. Format staje się 15-minutową cotygodniową „kontrolą gotowości”; te same wyniki (opisy, rozmiar, podział), ale mniejsza objętość, ponieważ patrzysz tylko na to, co jest blisko WIP granica.

Jeśli jesteś scrumbanem, uruchom 30-minutowy format scrum.

A co z zespołami posiadającymi Właściciela Produktu?

PO pisze opisy zadań i decyduje o priorytecie. Zespół inżynierów dokonuje szacunków i rozdziela flagi. Spotkanie to PO i inżynierowie w tym samym pomieszczeniu. PO nie szacuje.

Typowy tryb awarii: PO pisze 3-wierszowy opis, zespół go szacuje i dopiero później zdaje sobie sprawę, że w opisie brakowało kluczowego kontekstu. Rozwiązanie polega na tym, że zespół pyta „jak wygląda gotowe dla użytkownika?” za każdy zadanie, a nie tylko „czy opis jest kompletny?”; opisy mogą wyglądać na kompletne, a mimo to nie odpowiadać rzeczywistym oczekiwaniom użytkownika.

Koszt złego zrobienia tego

Zespół, który całkowicie pominie udoskonalanie, traci ~2 godziny na sprint na pytanie „Co to oznacza?” rozmowy podczas planowania oraz odkrycie w połowie sprintu, że praca była większa, niż szacowano. Dla 6-osobowego zespołu to ~3000 funtów za każdy sprint zmarnowanego czasu inżynierskiego.

30-minutowe cotygodniowe udoskonalanie kosztuje zespół ~ 1000 funtów za sprint przy typowych kosztach inżynieryjnych w Wielkiej Brytanii. Matematyka jest prosta.

Jak to wygląda w SprintFlint

SprintFlint pokazuje zaległości z punktami historii, odznakami rozmiaru i znacznikiem „wymaga dopracowania” automatycznie zastosowanym do czegokolwiek w ciągu następnych 2 sprintów bez opisu i szacunków. Spotkanie udoskonalające przebiega w formie „spójrz na ten filtr, przejdź w dół listy”; żaden zadanie nie przejdzie.

Dla zespołów, które nie będą zmieniać narzędzi, tania wersja: filtr Linear/Jira dla priority > 0 AND points = empty AND sprint = next-two, uruchamiaj co tydzień.

TL;DR

• Udoskonalenie daje trzy rzeczy: opisy zadań, rozmiary, podziały. Nic więcej.
• 30 minut tygodniowo, jeden moderator. Pomiń tygodnie planowania.
• Właściwe pytanie do każdego zgłoszenia: „czy wiemy, jak wygląda „gotowe”?” A nie „jak to zbudujemy?”
• 5-minutowy twardy limit na zadanie. Większe rozmowy powodują gwałtowny wzrost, podział lub prośbę o wyjaśnienia.
• Nie udoskonalaj zgłoszeń, nad którymi nikt w zespole nie będzie pracował. Nie zapisuj zgłoszeń na spotkaniu. Nie mów o pracy polegającej na pięciu sprintach.
• Zespół, który pomija udoskonalanie, traci ~2 godziny na sprint z powodu zamieszania w planowaniu. 30-minutowe spotkanie temu zapobiega.