Techniki

Drugie dno szacowania

Większość osób nie lubi szacować pracy. Uzyskane wyniki bardzo często bywają błędne, stąd wielu z nich nie widzi większego sensu w szacowaniu, skoro finalnie i tak okazuje się to wyłącznie spekulacją. Idąc dalej, obawa przed możliwością niewywiązania się z obietnicy powoduje, że mało kto lubi odpowiadać na pytania o czas potrzebny na wykonanie pracy.

Warto dostrzec jednak drugie dno szacowania, a mianowicie okazję do wymiany oraz pogłębienia wiedzy dotyczącej konkretnego zagadnienia. Korzyść ta jest szczególnie wyraźnie widoczna w samowystarczalnych, interdyscyplinarnych zespołach.

Jak to wygląda w praktyce?

Dowolne wymaganie poddawane jest szacowaniu na dwóch poziomach:

  1. Historii Użytkownika (wysokopoziomowe), oraz
  2. zadań technicznych (niskopoziomowe).

Szacowanie Historii Użytkownika

Wyobraźmy sobie przykładową Historię Użytkownika:

Jako Użytkownik chcę mieć możliwość dodania przedmiotu do koszyka, tak abym mógł go kupić.

Zespół, po zapoznaniu się w wystarczającym stopniu z wymaganiami, korzystając np. z Planning Pokera, określa złożoność zadania. Padają następujące wartości:

3, 3, 1, 8

Wygląda na to, że członkowie Zespołu różnie określają złożoności zadania. Rozpoczyna się dyskusja. Osoba, która szacowała złożoność na 1, omawia dlaczego jej zdaniem jest to jedynka. Następnie osoba odpowiedzialna za oszacowanie złożoności na 8, przedstawia swój punkt widzenia. Po zakończonej dyskusji, Zespół ponownie szacuje skomplikowanie zadania:

3, 5, 3, 5

Ze względu na dalszą rozbieżność wyników, następuje kolejna runda szacowania. Uczestnicy znów podają swoje wartości. Cykl ten trwa to tak długo, aż Zespół, na skutek wymiany wiedzy, dojdzie do porozumienia w kwestii złożoności konkretnego zadania.

Ze względu na zgrubny charakter tych oszacowań, nie ma konieczności, aby poświęcać na tego typu szacowanie zbyt dużej ilości czasu.

Szacowanie zadań technicznych

Kiedy mogło by się wydawać, że mamy już gotowe oszacowanie, a poziom ogólnej wiedzy w Zespole jest zadowalający, przechodzimy do drugiej fazy szacowania. Zespół dekomponuje Historię Użytkownika na zadania techniczne, i tak dla wspomnianego wyżej przykładu otrzymujemy przykładowe zadania:

  • przygotowanie warstwy prezentacji
  • stworzenie logiki biznesowej
  • zrealizowanie testów
  • refaktoryzacja istniejącego kodu

Dla tych konkretnych zadań technicznych, Zespół podaje szacowany czas pracy w godzinach. I znów, kiedy widać duże rozbieżności w proponowanych wartościach, Zespół dyskutuje o konkretnym zadaniu technicznym tak długo, aż zostanie osiągnięte porozumienie.

Ze względu na fakt, iż zejście na poziom zadań technicznych oznacza, że zadaniem będziemy zajmować się w najbliższej perspektywie (iteracja, Sprint), wskazane jest aby dokonać tych oszacować z większą precyzją, aniżeli w przypadku zgrubnego szacowania Historii Użytkownika.

Podsumowanie

Warto traktować szacowanie pracy nie tylko jako narzędzie dostarczające konkretne wartości liczbowe przydatne do planowania, ale także jako okazję do pogłębienia wiedzy o wymaganiach w Zespole. Dodatkowo, członkowie Zespołu mogą się wiele od siebie nauczyć – szczególnie, jeśli dysponują różnym doświadczeniem, a platforma na której pracują jest skomplikowana.

Photo by Scott Webb on Unsplash

Moje najbliższe warsztaty

Warsztaty „Labirynty Scruma” — Warszawa — 26-27 marca 2020
Chcesz dowiedzieć się, jak usprawnić swojego Scruma i omijać najczęstsze pułapki?
Dołącz na 2-dniowe warsztaty i przepracuj ze mną na żywo, jak radzić sobie z pułapkami w Scrumie. 100% praktyki, zero teorii.

Zapisz się na warsztaty >>
Jacek Wieczorek
Jestem konsultantem zwinności i praktykiem podejścia agile. Napisałem książkę "Labirynty Scruma" o sprawdzonych sposobach na najczęstsze pułapki w Scrumie. Pomagam przekształcać organizacje w miejsca, w których efektywnie tworzone są wartościowe produkty. Prowadzę bloga jacekwieczorek.pl, współtworzę podcast Porządny Agile oraz portal Agile247. Na co dzień pomagam klientom działając jako konsultant w firmie 202 Procent, którą współtworzę z pasjonatami zwinności.
Mogą Cię zainteresować poniższe wpisy
Dot voting, czyli nadawanie priorytetów głosując kropkami
Jak utrzymać timebox na Daily Scrum?

Zostaw swój komentarz

Twój komentarz*

Twoje imię*
Twoja strona*

This site uses Akismet to reduce spam. Learn how your comment data is processed.