Estymacje to temat wciąż elektryzujący zespoły pracujące w środowisku zwinnym. Podczas naszego grudniowego warsztatu o estymowaniu organizowanego w ramach Agile Wrocław, w kuluarach, rozmawialiśmy krótko i bez zagłębiania się w temat o zadaniach, które nie zostają ukończone w sprincie i tym, co dzieje się z ich estymacjami. Po wydarzeniu napisał do mnie Paweł (serdecznie dziękuję za zgodę na udostępnienie korespondencji!), który pogłębił wątek i zainspirował mnie do napisania tego artykułu – poniżej znajdziecie naszą wymianę zdań.
E-mail Pawła
Cześć!
[…]
Na warsztacie Agile Wrocław powiedziałaś, że jeśli w danym sprincie nie skończyliśmy zadania/historyjki i część zadania przechodzi na następny sprint, to nie zmieniamy pierwotnej estymacji. Argumentacja dlaczego tak robić była słuszna i moje zespoły też kiedyś tak chciały to robić, jednak potknęliśmy się na ograniczeniach (albo nieumiejętności zastosowania) Jiry. Zaplombowaliśmy problem, ale szukam lepszego rozwiązania.
I teraz przechodząc na Jirę, o której mówiłaś że korzystasz:
- Wpisujemy estymatę do “Original Time Estimate” (OTE) i obserwujemy bieżący postęp prac w sprincie na Burndown Chart, który jest oparty na OTE. Zależy nam, żeby obserwować czy prace idą płynnie czy coś się zacięło. Jeśli przed uruchomieniem sprintu nie zaktualizujemy OTE dla zadań wziętych na ten sprint, to wykres będzie dawał fałszywe sygnały.
- Według nas korzystanie w tym celu z wykresu spalania opartego na Remainig Time Estimate nie spełnia tej funkcji, ponieważ RTE nie mówi o tym czy zadanie zostało zakończone. Wykres RTE bardziej pokazuje spalanie godzin niż tworzenie wartości dla klienta.
- W związku z tym:
- modyfikujemy OTE na planingach i refinementach
- nasz OTE to tak naprawdę OTE dla sprintu, nie dla projektu
- suma przyszłych OTE pozwala nam określić kiedy skończymy projekt – to jest OK
- niestety suma OTE zakończonych zadań nic nam nie mówi, bo straciliśmy dane o pierwotnych estymatach. To bardzo przeszkadza w wyciąganiu wniosków w dłuższym okresie.
- potem uruchomiliśmy budżetowanie projektów oparte na Earned Value, które wymaga historycznych estymat, i to zdopingowało nas do takiego rozwiązania: kopiujemy pierwotne OTE do specjalnie założonego pola, którego nie modyfikujemy dzieląc zadania. Niestety to jest podatne na błędy – zwyczajnie łatwo zapomnieć o skopiowaniu lub aktualizacji.
I tu pytanie: co możemy zrobić inaczej, czego nie widzimy? Czy mogłabyś coś podpowiedzieć?
Pozdrawiam, Paweł
Moja odpowiedź
Cześć Paweł!
Bardzo Ci dziękuję za pytanie 🙂 […]
Zanim odniosę się do Twojego sposobu radzenia sobie z tematem niedokończonych zadań w sprincie, opiszę, jak działa to od lat w moich zespołach. Estymacje określamy w Story Pointach, używamy do tego jednego pola w Jira (Story Points). Gdy zespół nie dokończy zadania w sprincie, nie zmieniamy jego estymacji, ale rozmawiamy o pracy pozostałej do wykonania w kolejnej iteracji. Przykład:
- Zadanie A zostało wyestymowane na 5 punktów, zadanie B na 2 i zadanie C na 3.
- Deweloperzy na planowaniu zastanawiają się ile jeszcze punktów kosztować będzie nas praca w kolejnej iteracji; z tej dyskusji wynika, że zadanie A potrzebuje jeszcze 2 punktów pracy a zadania B i C po 1 punkcie.
- Sumujemy pozostałą pracę ze wszystkich niedokończonych zadań i dostajemy wartość 4 punktów.
- Estymacje widniejące w Jira to nadal 5 + 2 + 3 = 10, ale realnie pracy zostało dla tych zadań na 4 punkty.
Następnie, planując odejmujemy od przyjętego velocity pozostałe 4 punkty i pozostałą pulę pojemności pracy zespołu wypełniamy nowymi elementami backlogu
Co nam to daje? Jira na podstawie estymacji, których nie zmieniamy pokazuje nam wykres Velocity Chart i dzięki niemu wiemy, jak kształtowała się prędkość pracy zespołu w sprintach. Velocity jest średnią, więc nie ma znaczenia, w którym sprincie praca zostanie ukończona (z perspektywy tej miary). Średnia i tak uwzględni tę wartość. Dodatkowo, patrząc na Velocity pojedynczego sprintu, widzimy ilość pracy ukończonej, czyli takiej, która jest potencjalnie gotowa do wydania – a zadania z przykładu, których nie skończyliśmy, nie mogą być pracą ukończoną. Wiemy wtedy nad czym pracować, by szacowania były bliższe rzeczywistości.
A teraz odnosząc się do Twojego sposobu – myślę, że moglibyście zastosować dwa podejścia:
- Gdy historyjka nie zostanie ukończona w całości, możecie ją podzielić na dwie np. ABC cz. 1 i ABC cz. 2; w cz. 1 zostanie w OTE wpisana wartość jaka wg Was została już poświęcona na pracę nad zadaniem w kończącym się sprincie, a w OTE cz. 2 wpiszecie nową wartość, jaka pozostała do wykonania w sprincie kolejnym. Czyli, jeśli zadanie X było wycenione na 5 i taka jest wartość OTE, a w kolejnym sprincie musicie dokończy jeszcze 2, to dzielicie zadanie na X cz. 1 i modyfikujecie OTE na 3, a w X cz. 2 dajecie pozostałe 2. Wada -> potencjalnie każdy wykres spalania będzie kończył się idealnie – nie zobaczycie historycznie wtedy na wykresach, że notorycznie nie udało się ukończyć wszystkich założonych na sprint zadań (będzie to można sprawdzić po ilości podzielonych zadań, co dodaje dużo żmudnej pracy).
- Drugi sposób, to zastosowanie mojego podejścia opisanego wyżej :), bez modyfikowania estymat i z przenoszeniem całych zadań do kolejnych iteracji. Wykresy velocity pomogą wam wyciągać średnią prędkość, a burndown chart pokaże gdzie jesteśmy z pracą w sprincie.
Daj znać proszę, czy pomogłam, a jeśli coś jest nadal niejasne lub nie rozwiązuje problemu jaki opisałeś, podyskutujmy dalej!
[…] Pozdrawiam!
Basia
Jak to jest z tymi estymacjami nieskończonych zadań?
Paweł chce przedyskutować wspomniane rozwiązania z zespołem – i jest to bardzo słuszne podejście. Estymacje nie tylko służą Product Ownerowi, ale także i tym, którzy nad zadaniem bezpośrednio pracują. Mam nadzieję, że uda poznać się nam dalszą część tej historii i wynik adaptacji :).
Jako Product Owner dbam o to, by estymacje umożliwiały planowanie działań wprzód – a gdy coś “ucieka” i znika, rzeczywistość staje się niejasna. Tu mam na myśli velocity – gdy historyczne dane giną, nie mamy opcji na rzetelną informacje o naszej średniej prędkości pracy.
Myślę, że niezależnie od przyjętych rozwiązań, utrzymanie danych historycznych jest najważniejsze. I oczywiście, umiejętnie z nich korzystanie!
A jak jest u Was? Podzielcie się!
Sprawdź nasze ostatnie wpisy:
