Antywzorce w Scrumie – czego unikać? Część 2: Planowanie Sprintu

Anty-wzorce w Scrumie

Anty-wzorce w Scrumie

Jakiś czas temu na łamach agile247.pl pojawił się pierwszy z serii artykuł dotyczący anty-wzorców w Scrumie. Dzisiaj przyszła kolej, aby przeanalizować kolejne zdarzenie Scrumowe, a mianowicie Planowanie Sprintu (ang. Sprint Planning).

Poniżej znajdziecie subiektywne TOP 5 anty-wzorców dotyczących planowania Sprintu.

Sprint Planning: anty-wzorzec #1 (Refinement zamiast Planningu)

Po czym poznać? Członkowie Zespołu Deweloperskiego podczas Planowania Sprintu wykonują czynności typowe dla sesji pielęgnowania Product Backlogu (ang. refinement, wcześniejsza, wycofana nazwa: grooming), czyli tworzą elementy backlogu, uszczegóławiają je, dodają kryteria akceptacji, estymują czy też dzielą na mniejsze części.

Jakie są konsekwencje? Efektem tego anty-wzorca jest niezaplanowanie pracy na Sprint, ponieważ czas przeznaczony na planowanie zostanie skonsumowany na czynności związane z pielęgnacją Product Backlogu. Brak planu znacząco zwiększa ryzyko niepowodzenia Sprintu, co niejednokrotnie miałem okazję doświadczyć na własnej skórze. Oczywiście może się zdarzyć stytuacja, w której Product Owner przyniesie na Planowanie nowe zadanie dla zespołu wymagające omówienia, jednak co do zasady nie powinna być to reguła.

Co można zrobić inaczej? Zazwyczaj identyfikacja tego anty-wzorca to dopiero szczyt góry lodowej, związany najczęściej z brakiem cyklicznych sesji pielęgnacji Product Backlogu. Poniżej trzy proste podejścia, które zwyczajowo pomagają:

  • zaplanowanie regularnych sesji pielęgnacji Product Backlogu – fakt, że w podejściu zwinnym nie występuje długotrwała faza planowania, nie oznacza, że wymagania nie są omawiane. Dzieje się to w każdym Sprincie i zwyczajowo poświęca się na to ok. 10% czasu Sprintu (czyli 3,5h dla 1-tygodniowego Sprintu). Istnieje wiele podejść do wykorzystywania dostępnego czasu, np.
    • jednorazowa, długa sesja refinementu raz w tygodniu
    • codzienne omawianie jednego elementu z Product Backlogu np. po Codziennym Scrumie
    • dwie lub trzy sesje rozłożone w trakcie trwania Sprintu

Każde z wyżej wymienionych podjeść ma zarówno wady jak i zalety, co jednak wykracza poza zakres tego wpisu. Z drugiej strony, brzmi jak dobry temat na nowy artykuł 🙂

  • przeprowadzanie Przeglądu Sprintu zamiast sesji demo – częstym anty-wzorcem – o którym napiszę więcej w kolejnych odcinkach – jest traktowanie Przeglądu Sprintu wyłącznie jako okazji do przedstawienia Product Ownerowi oraz interesariuszom nowych funkcjonalności produktu. To, co powinno się zadziać oprócz “przeklikania” nowych rzeczy, to aktualizacja Product Backlogu na podstawie wiedzy, którą zdobędziemy od interesariuszy. Zazwyczaj podczas Przeglądu Sprintu jest czas, aby zastanowić się nad kolejnością elementów, będących najwyżej w Product Backlogu, dodać nowe elementy lub usunąć te, które są już niepotrzebne.
  • wprowadzenie DoR (ang. Definition of Ready) – jest to zwyczajowo prosta checklista, która określa, co to znaczy, że element Product Backlogu jest gotowy, aby wziąć go pod uwagę podczas Planowania Sprintu. Lista ta może być unikatowa dla każdego zespołu. Przykładowe, proste DoR mogłoby wyglądać następująco:
    • wymaganie zapisane jest w formie User Story
    • User Story spełnia zasadę INVEST
    • kryteria akceptacji są jasno określone
    • element jest wyestymowany
    • estymata jest mniejsza niż 13 punktów

Sprint Planning: anty-wzorzec #2 (Brak planu dostarczenia Sprintu)

Po czym poznać? Zespół przeprowadza Planowanie Sprintu, jednak efektem nie jest plan dostarczenia Sprintu. Warto zaznaczyć, że sama lista elementów Product Backlogu, nawet poszerzona o zadania techniczne, nie jest wystarczającym planem.

Jakie są konsekwencje? Po Planowaniu Sprintu zespół jako całość nie ma obrazu tego, co wydarzy się w ciągu najbliższych dni. Wie, że są pewne zadania do wykonania, jednak brakuje zrozumienia, w jaki sposób elementu Product Backlogu zostaną zamienione na działające oprogramowanie.

Co można zrobić inaczej?

  • przygotować faktyczny plan -przyjmuje on najczęściej postać diagramu, rysunku lub po prostu listy kroków, które muszą zostać wykonane, aby osiągnąć Cel Sprintu. Warto rozważyć takie obszary jak:
    • kolejność wykonywania zadań
    • osadzenie w czasie
    • ważność wykonywanych kroków
    • zależności zewnętrzne (np. z innymi zespołami/dostawcami)
    • zależności wewnętrzne (np. zależność frontendu aplikacji z backendem)
    • wszelkie niejasności
    • ryzyka
  • spędzić więcej czasu na drugiej części planowania – pierwsza część planowania odpowiada na pytanie “co zostanie zrealizowane”, druga część na pytanie “jak zostanie zrealizowane”. Przy dobrze przygotowanym Product Backlogu, pierwsza część planowania trwa krótko (max. 30 minut), więc dla 1-tygodniowego Sprintu pozostaje 1h 30 minut na zaplanowanie, jak zostanie wykonana praca.
  • poprosić osobę z Zespołu Deweloperskiego o opowiedzenie własnymi słowami, jak rozumie plan Sprintu – ta prosta technika daje szybką odpowiedź, czy plan jest zrozumiały dla Zespołu Deweloperskiego. Gdy plan jest niedostatecznie szczegółowy, najprawdopodobniej ktoś z zespołu odezwie się w z wypowiedzią w stylu “chwila chwila… zanim zaktualizujemy bazę danych, muszę uruchomić kilka skryptów”. Jest to okazja, aby uszczegółowić niejasny element (lub elementy) planu.

Sprint Planning: anty-wzorzec #3 (Brak Celu Sprintu)

Po czym poznać? Zespół wybiera elementy Product Backlogu, które prognozuje dostarczyć w nadchodzącym Sprincie, jednak nie powstaje Cel Sprintu, który jest wskazówką dla Zespołu Deweloperskiego, co powinno być efektem końcowym iteracji.

Jakie są konsekwencje? Zespół nie ma jasnej informacji, dlaczego realizuje wybrany przyrost. Komunikowanie powodów, dla których realizujemy konkretne zadania, jest istotne dla zrozumienia kontekstu biznesowego realizowanego produktu. Dodatkowo, brak wspólnego celu dla zespołu może spowodować, że zamiast współpracować nad realizacją Celu Sprintu, członkowie zespołu będą pracować “na własną rękę” nad pojedynczymi zadaniami, co może doprowadzić do niespójności na koniec Sprintu (np. “myślałem, że w tym zadaniu inaczej przygotujesz API”). Zespół potrzebuje pewnego spoiwa, które zapewni, że będą poruszać się w tym samym kierunku.

Co można zrobić inaczej?

  • zacząć Planowanie Sprintu od dyskusji na temat Celu Sprintu – taka dyskusja pomaga dotrzeć do potrzeb Product Ownera, które nie zawsze są wyrażone w czytelny sposób w postaci elementów Product Backlogu. Pomocne mogą być pytania, skierowane do Product Ownera:
    • “co chciałbyś otrzymać na koniec Sprintu?”
    • “jaki cel biznesowy kryje się za elementami, które zaproponowałeś na bieżący Sprint?”

Sprint Planning: anty-wzorzec #4 (Planowanie na wyczucie)

Po czym poznać? Zespół podczas Planowania Sprintu nie bierze pod uwagę metryk oraz danych historycznych. Decyzja dotycząca ilości oraz doboru elementów, które zespół prognozuje dostarczyć, podejmowana jest “na wyczucie”. Niekorzystanie z dostępnych danych najczęściej wynika z faktu, że nie są kolekcjonowane.

Jakie są konsekwencje? Zwiększone ryzyko związane z realizacją bieżącego Sprintu. Cała wiedza zdobyta przez Zespół Deweloperski dotycząca procesu nie jest wykorzystywana.

Co można zrobić inaczej? Poniżej kilka przykładów wykorzystania metryk oraz danych historycznych:

  • historyczna prędkość zespołu (ang. velocity) – prędkość zespołu informuje, jak dużo Zespół Deweloperski jest w stanie dostarczyć w trakcie pojedynczego Sprintu. Podczas Planowania Sprintu przydatne jest spojrzenie na:
    • ostatnią prędkość zespołu (tzw. “yesterday weather”), oraz
    • średnią prędkość z kilku ostatnich Sprintów
  • przewidywalność zespołu – jest to stosunek tego, co dostarczyliśmy w Sprincie, w stosunku do tego, co planowaliśmy dostarczyć. Przykładowo, jeśli na koniec Planowania Sprintu Zespół Deweloperski prognozuje, że dostarczy 100 Story Pointów, a na koniec Sprintu dostarcza 80 Story Pointów, to przewidywalność tego zespołu wynosi 80%. Warto spojrzeć na historyczne rezultaty, aby ocenić, czy częściej mamy problem z niedoszacowaniem, czy też z przeszacowaniem zadań.
  • trafność estymat – technika szczególnie skuteczna jeśli chodzi o identyfikację ryzyk. Każde zadanie, które zrealizowaliśmy w Sprincie ponownie estymujemy, kiedy zostanie już zrealizowane. Pozwala to stworzyć tabelkę, która z czasem powie nam, jak trafnie estymujemy poszczególne rozmiary zadań, np. 1 Stor Point = 98%, 2 Story Pointy = 95%, 3 Story Pointy = 87% itd. Im wyższa estymata (bardziej złożone zadanie), tym mniejsza szansa na prawidłowe określenie estymaty. Podejście to pozwala określić liczbę Story Pointów, których przekroczenie powoduje, że zespół nie bierze takiego zadania do Sprintu z powodu zbyt dużego ryzyka, że zadanie okaże się większe niż się spodziewaliśmy.
  • średnia liczba zrealizowanych elementów per Sprint – jeżeli elementy, które realizujemy są podobnej wielkości, możemy zliczać przepustowość naszego procesu (np. realizujemy 15 elementów z Product Backlogu per Sprint). Jest to zaawansowane podejście, wymaga bowiem dużej wprawy w przygotowywaniu naprawdę małych elementów Product Backlogu, jednak w efekcie daje duże możliwości. Dla zainteresowanych tego rodzaju podejściem odsyłam do artykułu dotyczącego ruchu #noestmates.

Sprint Planning: anty-wzorzec #5 (Planują wyłącznie programiści)

Po czym poznać? Wyłącznie programiści z Zespołu Deweloperskiego biorą aktywny udział w Planowaniu Sprintu. Reszta zespołu (testerzy, UX, analitycy, devops, …) biernie uczestniczy w spotkaniu.

Jakie są konsekwencje? Zespół planuje pracę tylko przez pryzmat prac programistycznych. Pozostałe obszary produktu – konieczne, aby dostarczyć zbywalny kawałek oprogramowania – pozostają nieomówione. Łatwo wpaść w pułapkę niedoszacowania ryzyk, np. gdy deweloperzy oceniają element Product Backlogu jako prosty programistycznie, nie zdając sobie sprawy, ze zmiana może być bardzo wymagająca jeśli chodzi o testy. Może to też doprowadzić do gorącego okresu pod koniec Sprintu, gdy po luźnym z testerskiego punktu widzenia początku Sprintu, nagle duża część elementów realizowanych w Sprincie będzie wymagała przeprowadzenia testów.

Co można zrobić inaczej? Poniżej dwa proste podejścia, które pozwolą zaangażować cały zespół:

  • praca w małych, wymieszanych grupach – na początku planowania dzielimy Zespół Deweloperski na małe 2-3 osobowe grupy, składające się z jak największej liczby kompetencji (np. programista + tester + UX). Następnie zespół pracuje w grupach, co pozwala na spojrzenie na zadanie z różnych perspektyw. Pełny opis tej techniki można znaleźć tutaj.
  • zmoderować spotkanie – rozwiązanie to brzmi banalnie, jednak czasem właśnie dobra moderacja jest tym, czego brakuje. Czujny moderator wyłapie sytuacje, w której wyłącznie programiści dyskutują i odpowiednim pytaniem (“A jak to zadanie wygląda z perspektywy QA?”) lub obserwacją (“Widzę, że tylko programiści biorą udział w dyskusji”) aktywuje pozostałe role.

Podsumowanie

Planowanie Sprintu to jedno z najważniejszych zdarzeń w Scrumie. Potencjał tego wydarzenia jest ogromny, jeśli tylko wiemy, jak z niego skorzystać. Słabo zaplanowany Sprint z reguły prowadzi do kiepskiego Sprint Review oraz owocuje grymasami niezadowolenia interesariuszy. Tego chyba chcemy uniknąć, prawda?

Standardowo zapraszam do dyskusji – jakie anty-wzorce są największym wrogiem Planowania Sprintu z Waszej perspektywy? Koniecznie dajcie znać w komentarzach.

Chcesz przeczytać więcej?

Powyższy artykuł to mały wycinek mojej książki “Labirynty Scruma”, której premierę planuję w okolicy połowy 2017 roku. Opisuję w niej sprawdzone, praktyczne sposoby na najczęstsze pułapki w Scrumie. Zapisz się na mój newsletter – dla subskrybentów planuję przedpremierowy fragment książki oraz dodatkowe materiały.

Źródło zdjęcia: https://flic.kr/p/61KvuL

Komentarze do wpisu: “Antywzorce w Scrumie – czego unikać? Część 2: Planowanie Sprintu

  1. Jacku,

    Co stoi na przeszkodzie by refinement i planowanie złączyć w jedno wydarzenie? Zakładam, że trzeba poświęć na to odpowiednią ilość czasu i że efektem planowania będzie plan dostarczenia sprintu, a więc konsekwencja, o której piszesz („Efektem tego anty-wzorca jest niezaplanowanie pracy na Sprint”) nie występuje.

    Refinement (z udziałem całego zespołu, dzieleniem historii na zadania, szacowaniem) pośrodku sprintu wydaje mi się czymś co wybija z rytmu w pracach nad celem sprintu (przełączanie kontekstu). Piszę „wydaje mi się”, bo właśnie zazwyczaj łączymy te wydarzenia i nie zweryfikowałem tej tezy… Jeszcze 🙂

  2. Jacek Wieczorek

    Hej Paweł,

    dzięki za Twój komentarz.

    Czy możesz napisać więcej, w jaki sposób przebiega takie łączone spotkanie w Twoim zespole? Pozwoli mi to precyzyjniej odpowiedzieć na pierwszą cześć Twojego pytania.

    Natomiast napisałeś wystarczająco, aby odpowiedzieć na Twoją wątpliwość dotyczącą przełączania kontekstu. Jeżeli refinementy są zaplanowane – tzn. Zespół Scrumowy ma je na stałe w swoim grafiku na Sprint, to paradoksalnie spotkania te wyznaczają zdrowy i przewidywalny rytm pracy dla całego Zespołu Scrumowego. Czyli przykładowo, dla 1-tygodniowego Sprintu, cały zespół wie, że:

    – w poniedziałek zaczynamy Planowaniem Sprintu,
    – od rana we wtorek mamy refinement (patrzymy w Product Backlog dalej niż najbliższy Sprint),
    – cała środa to czysty dewelopment, bez innych spotkań
    – w czwartek od rana – dla bezpieczeństwa przed kolejnym Planowaniem Sprintu – przeglądamy Product Backlog na refinemencie (patrzymy na elementy planowane na najbliższy Sprint),
    – w piątek od rana dewelopment, po południu Przegląd Sprintu + Retrospektywa.

    Oczywiście, jeśli refinementy nie są zaplanowane i w sposób losowy i chaotyczny wyrywają Zespół Deweloperski z pracy, to faktycznie możemy mówić o przełączaniu kontekstu – ale to z kolei brzmi to jak anty-wzorzec 🙂

    Inna konsekwencja jest następująca – skoro łączysz refinement z Planowanie Sprintu oznacza to, że refinement występuje raz w trakcie trwania Sprintu. Powoduje to, że masz tylko jedną okazję na cały Sprint (zapewne 1 lub 2 tygodnie) na przegląd Product Backlogu. W tak złożonym i zmiennym środowisku, jakim jest software dewelopment, uważam to za wysoce ryzykowne, aby tak rzadko aktualizować wymagania.

    Co w przypadku, gdy elementy Product Backlogu okażą się absolutnie niejednoznaczne dla Zespołu Deweloperskiego? Wtedy następną okazję, aby podejść do ich rozpracowania masz w kolejnej iteracji – to naprawdę zbyt dużo czekania. Refinement to proces ciągły, który ma zapewnić gotowość Product Backlogu w przód, na najbliższe Sprinty. Często jeden element PB jest omawiany i uzupełniany o detale na kilku oddzielnych sesjach, wraz ze wzrostem wiedzy na temat wymagania zarówno po stronie Product Ownera, jak i po stronie Zespołu Deweloperskiego.

    Jestem świadkiem sytuacji, w których Zespół Scrumowy kilkukrotnie podchodzi w ciągu 1-tygodniowego Sprintu 3 razy do zadania, które pozostaje niejasne, np. w poniedziałek, środę oraz piątek. Pomiędzy poniedziałkiem a środą oraz środą i piątkiem zarówno Product Owner jak i Zespół Deweloperski zdobywają brakującą wiedzę oraz kontekst, potrzebny do zrozumienia potrzeby biznesowej. Całkowity czas rozwiania wątpliwości to 1 tydzień. To samo zadanie, omawiane przy okazji refinementu połączonego z Planowaniem Sprintu zajęło by 3 tygodnie. Dla wielu klientów taki czas oczekiwania jest nieakceptowalny, zresztą będąc po stronie dostawcy odpowiedzialny za proces deweloperski również nie akceptuję tak wydłużonego oczekiwania.

    Liczę na Twoją odpowiedź, abyśmy mogli pogłębić temat.

    • Dzięki za odpowiedź. Mam teraz tematy do przemyśleń 🙂

      Podczas sprintu dyskutujemy i porządkujemy backlog, ale odbywa się to dość spontanicznie. Czytając Twoją odpowiedź, zdałem sobie sprawę, że rzeczywiście ta spontaniczność może wybijać z kontekstu. Nieregularność ma swoje zalety (porządkujemy kiedy potrzebujemy), ale też główną wadę – łatwiej pominąć dane zdarzenie czy proces, gdy brak dyscypliny.

      Odpowiadając na Twoje pytanie – poniżej przebieg spotkania planującego bieżący sprint (pracujemy w 1-tygodniowych sprintach):

      11:00 – rozpoczynamy spotkanie.

      Góra backlogu ma nadane priorytety i jest w większości podzielona na funkcjonalności o takiej wielkości, że są wystarczająco małe by mogły być w sprincie.

      Bierzemy pierwszą funkcjonalność – omawiamy jej cel, zastanawiamy się czy jest coś zbędnego co da się jeszcze wykroić, wypisujemy zadania techniczne, które należy wykonać oraz detale, które trzeba wziąć pod uwagę.
      Szacujemy – planning poker – 3 rozmiary koszulek + too f* big.

      Robimy to dla kolejnych historii.

      Znamy naszą średnią prędkością z 3 poprzednich sprintów i omawiamy oraz szacujemy kilka funkcjonalności więcej niż te, które zmieszczą się w sprincie (na wypadek pomyślnych wiatrów i chęci by wziąć do sprintu więcej).

      Ustalamy zakres sprintu i planujemy kto co zrobi w pierwszym dniu/dniach sprintu.

      Cel sprintu – często jest jasny na początku sprintu, czasem klaruje się przy końcu planowania. Zapisujemy na tablicy.

      12:45 – kończymy spotkanie.

      Czas ok, ale zespół jest niewielki.

      Być może ten ostatni warunek też jest dość istotny. Poprzedni zespół, w którym pracowałem, działał na podobnej zasadzie, ale był nieco większy i dużo szybszy, a więc zakres funkcjonalności do omówienia był dużo większy. Takie planowanie rozwlekało się i było dość wyczerpujące.

      • Paweł,

        ja spotkałem się z problemem, że zespoły były duże, zakres pracy również i przy podejściu, że planowanie to również refinement, całe to spotkanie trwało długo. Za długo. Dlatego wydzielenie pielęgnacji spowodowało, że mieliśmy tę samą robotę rozłożoną w czasie i tak nie bolało. Refinement był dokładnie w środku sprintu, cyklicznie i każdy wiedział, że *zawsze* musi się odbyć o tej samej porze. Robienie tego ad hoc niesie ze sobą ryzyko, że może ono się nie wydarzyć w ogóle, bo są ważniejsze rzeczy.

        Dobrze poprowadzony refinement powodował, że planowanie trwało nawet 15 min (PO dawał cel, zespół upewniał się o jakie US-y chodzi i po wszystkim).

      • Jacek Wieczorek

        Paweł – dzięki za rozwinięcie tematu.

        Po tym co napisałeś, to pierwsze, co przyszło mi do głowy, to ryzyko związane z późnym estymowaniem zadań. Pytanie, jaki macie typowy rozkład estymat podczas planning pokera. Wyobrażam sobie sytuację, w której zadania dostają wysokie estymaty (łącznie z TFB), co powoduje, że pomimo iż trwa Planowanie Sprintu, musicie wykonać zadania typowe dla refinementu (np. dzielenie zadań, dodawanie szczegółów, estymowanie). Powoduje to, że możecie stracić czas na właściwe Planowanie Sprintu, co może wpłynąć na jakość zaplanowania pracy.

        Z drugiej strony po Twoim opisie wnioskuję, że Product Backlog jest nieźle przygotowany (zadania na tyle małe, że mieszczą się Sprincie; nadanie priorytety), więc ktoś wcześniej najwyraźniej wykonał jakąś pracę związaną z przygotowaniem Product Backlogu. Jeśli dołożymy do tego, że macie mały zespół oraz że np. dobrze znacie produkt, to pewne ryzyka mogą nigdy się nie zmaterializować.

  3. Cześć,

    zastanawia mnie Anty-wzorzec #4 (planowanie na wyczucie).

    Parę razy spotkałem się z sytuacją, że zespół brał na sprint więcej niż wskazywało na to velocity. I dowoził. Czyli wyczucie działało. A zaoszczędzono czas na podwyższenie trafności szacowania.

    Jak ma wyglądać takie spotkanie „trafność estymat”. Do czego odnosi się np 1 Story Point = 98%, 2 Story Pointy = 95%, 3 Story Pointy = 87%. Tzn co jest wzorcem i jak mierzymy odchylenie.

    Czy coś więcej można na ten temat napisać?

    pozdrawiam,
    Bartek

    • Jacek Wieczorek

      Bartek,

      dzięki za Twój komentarz.

      Piszesz, że zespół brał na sprint więcej niż wskazywało na to velocity. Oznacza to, że zespół ma jakiś punk referencyjny (velocity) wynikający z ich doświadczenia. To, że zdecydują się w ramach prognozowanego zakresu na nieco więcej niż wskazują dane historyczne, to przecież nic złego.

      W jednym z zespołów, w których byłem Scrum Masterem, team dosyć długo podnosił sobie poprzeczkę właśnie poprzez „branie” nieco więcej niż wskazywało im velocity. Oczywiście dotarli do naturalnej granicy prędkości dla tego zespołu i wynik nie rósł im w nieskończoność 🙂

      Gorsza sytuacja jest, kiedy nie ma podobnego punktu referencyjnego i prognoza zakresu Sprintu jest budowana absolutnie na wyczucie. Można i tak, i co więcej, może się tak długo udawać trafiać. Jednak osobiście w ramach minimalizowania ryzyka związanego z dużą złożonością i nieprzewidywalnością środowiska, preferuję opieranie się na dostępnych danych.

      Nawiązując do Twojego pytania – trafność estymat możesz liczyć dla dowolnego odcinka czasu, czyli np. dla ostatnich 10 Sprintów.

      W takim przypadku liczysz wszystkie zadania, które przed wejściem do Sprintu były wyestymowane na 1 Story Point. Załóżmy, że takich zadań w ciągu ostatnich 10 Sprintów było 20.

      Następnie analizujesz wszystkie zadania, które pierwotnie wyestymowane były na 1 SP, jednak po dokonaniu reestymacji na koniec Sprintu, okazywały się większe lub mniejsze od pierwotnej estymaty (czyli na moment estymacji myliliśmy się do rozmiaru, co nie jest w sumie niczym zaskakującym). Załóżmy, że takich zadań było 15.

      Kiedy podzielisz liczbę zadań, który estymata się nie zmieniła (15) przez liczbę wszystkich zadań wyestymowanych pierwotnie na 1SP (20) przez liczbę zadań, dostaniesz wynik w procentach, w tym przypadku 75%. Oznacza to, że historycznie patrząc mamy 75% szans na to, że zadanie wyestymowane na 1 SP faktycznie ma taki rozmiar.

      Mam nadzieję, że powyższe wytłumaczenie jest czytelne. Jeśli nie – pisz.

      • Jasne, dzięki.

        A na ile zespoły chętnie robią estymacje pod zakończonej pracy? Ile jest w tym wartości?

        Oprócz klasycznego marudzenia „a po co nam jeszcze kolejne spotkanie”, to zastanawia na ile to rzeczywiście pomaga.

        Cały czas mówimy o szacowaniu. Czyli być może uda nam się być może zmniejszyć błąd, ale i tak ciągle to są przewidywania.

        Alternatywnym podejściem jest nie robić reestymat wszystkiego (najwyżej rzeczy mocno przestrzelonych mających wpływ na przyszłość) i dodać „przeczucie” zespołu, ale być przygotowanym na to, że czasem nie trafią i albo będą musieli dobrać coś z rożka nadziei albo po prostu nie dowiozą wszystkiego.

        Rzeczywiście reestymata wszystkiego opłaca się?

        • Jacek Wieczorek

          @Bartek – myślę, że to dobre ćwiczenie pokazujące, że mniejsze zadania = zmniejszona niepewność dostarczenia. Zgadzam się z Twoją refleksją, że nadal to tylko przewidywania. Czy się opłaca? Trudno mi ocenić w jakim stopniu macie z tym problem.

          Mogę sobie wyobrazić sytuację, że dochodzicie do konkluzji, np: że zadania większe niż 13 Story Pointów warto dzielić na mniejsze, bo aktualnie tylko 40% takich zadań faktycznie jest „trzynastkami”, a 60% to zadania zdecydowanie większe. Na skutek zdobycia tej wiedzy zaczniecie dzielić zadania na mniejsze, co zwiększy Waszą przewidywalność, a co za tym idzie zadowolenie waszych stakeholderów.

          Moja propozycja: zaproponuj w zespole eksperyment na 1-2 Sprinty, oceńcie jego efekt i koniecznie daj znać co wyszło.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

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

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x