Scrum - jak przenieść częściowo ukończoną Historię użytkownika do następnego Sprintu bez wypaczania zaległości

Używamy Scruma i od czasu do czasu stwierdzamy, że nie jesteśmy w stanie dokończyć historii użytkownika w sprincie, w którym została zaplanowana. W prawdziwym stylu Scrum, mimo to wysyłamy oprogramowanie i rozważamy włączenie historii użytkownika do następnego sprintu podczas następnej sesji planowania sprintu. Biorąc pod uwagę, że przenoszona przez nas historia użytkownika jest częściowo ukończona, jak oceniamy ją poprawnie w następnej sesji planowania sprintu? Rozważaliśmy:

a) Zmniejszenie liczby Punktów Opowieści, aby odzwierciedlić tylko pracę, która pozostała do ukończenia Opowieści użytkownika. Niestety będzie to popsuć zgłaszanie Backlogu produktu.

b) Zamknij częściowo ukończoną Historię użytkownika i podnieś nową, aby wdrożyć pozostałą część tej funkcji, która będzie miała mniej Punktów Historii. Wpłynie to na naszą zdolność do retrospektywnego sprawdzenia tego, czego nie ukończyliśmy w tym sprincie, i wydaje się to trochę czasochłonne.

c) Nie przejmuj się ani a, ani b i kontynuuj zgadywanie podczas planowania sprintu, mówiąc: „Cóż, ta historia użytkownika może być X punktami historii, ale wiem, że jest ukończona w 95%, więc jestem pewien, że możemy ją dopasować”.

W moim obecnym zespole robimy c).

Prędkość powinna uwzględniać rzeczy, które zespół naprawdę zakończył w sprincie. Coś, co nie zostało dostarczone, nie ma żadnej wartości dla klienta, więc nie liczymy za to żadnych punktów, to wszystko albo nic.

Przenosimy więc całą niedokończoną historię do następnego sprintu, a wszystkie jej punkty zostaną dodane do prędkości następnego sprintu. Prędkości wyrównują się w czasie i bierzemy średnią z kilku poprzednich sprintów jako odniesienie w celu ustalenia szacunkowych przyszłych prędkości.

Opcja A to powszechnie zalecany sposób działania. Nie przyznajesz punktów za ukończenie historii za poprzedni sprint i przeniesienie historii z powrotem do rejestru produktów, gdzie jest ona ponownie ustalana priorytetowo. Obliczasz swoją prędkość (i inne wskaźniki) na podstawie ukończonych historii użytkowników i wartości dodanej. Kiedy zaczynasz planować kolejny sprint, bierzesz historie o najwyższym priorytecie na podstawie ich wartości (która może, ale nie musi obejmować niedokończonej historii, jeśli priorytety biznesowe uległy zmianie). Oceniając historię, uwzględnij pracę, która została już wykonana przy uwzględnieniu nowej liczby punktów za historię.

Oczywiście alternatywną opcją (i moją preferencją) byłoby użycie pierwotnej szacunkowej liczby punktów opowieści, co zrobiłem w przeszłości. To sprawia, że ​​twoje oszacowanie było dobre i uzasadnione, ale ściągnąłeś za dużo pracy na sprint (np. - historia była w rzeczywistości warta 3 punkty, ale problem polega na tym, że ściągnąłeś 15 punktów historii, gdy powinieneś był rozebrać tylko 13). Jest to potencjalnie niebezpieczne założenie, jeśli nie masz pewności co do umiejętności dokonywania szacunków, ale może działać w oparciu o zespół i proces.

Wspominasz jednak, że to „zepsuje raportowanie Backlogu Produktu”. Backlog produktu i tak powinien być dynamiczny, a kolejność i szacunki każdej historii zmieniają się, ponieważ lepiej rozumiemy technologię, system, wymagania i klienta. Zazwyczaj raportuje się z Backlogu Produktu o liczbę historii użytkowników i całkowitą liczbę punktów historii. Należy się spodziewać, że zmienią się one wraz ze zmianami priorytetów, dodawaniem nowych wymagań, usuwaniem nieprawidłowych wymagań i zdobywaniem dodatkowych informacji.

Nadmierne myślenie o tym sprawia, że ​​wydaje się to bardziej skomplikowane niż jest w rzeczywistości ... To naprawdę dość proste:

Opcja C

Niekompletne historie wracają do rejestru produktów, bez zmiany punktów. Podczas planowania następnego sprintu i tego, co można zrobić, dyskusja powinna uwzględniać fakt, że znaczna część pracy została już wykonana. Jeśli zespół zdecyduje, że może zmieścić go w sprincie, wtedy wchodzi z pierwotną liczbą punktów. Jeśli nie, pozostaje w zaległościach. Gotowy. Punkty są przyznawane za sprint, w którym historia została ukończona.

Jeśli to pomoże, możesz śledzić osobny wskaźnik „pracy pozostałej” na historię użytkownika, aby jeśli pod koniec sprintu historia nie została ukończona, szacowaną pozostałą pracę można zanotować w historii i uwzględnić, kiedy planuje włączenie go do kolejnego sprintu. Ale nawet wtedy nie zmieniaj wartości punktowej oryginalnej historii.

Jeśli Twoje narzędzie do raportowania nie obsługuje dokładnie opcji A, wybrałbym opcję B, chyba że nie masz nadziei, że kiedykolwiek użyjesz tych danych.

W niektórych przypadkach możesz zrobić opcję B ORAZ nie przekrzywić tego, co oznacza zamknięcie, zawężając zakres starego zadania, które zamierzasz zamknąć, i tworząc tylko nowe zadanie dla zakresu, który pozostaje. To sprawia, że ​​historia ma sens w sensie semantycznym i zwykle wskazuje miejsca, w których powinieneś rozważyć dalsze rozbicie zadania. Czasami nie jest to możliwe ani logiczne, a po prostu masz tak duże zadanie lub napotykasz problemy.

edycja: Zakłada się (jak sądzę, że OP założyło), że prawie ukończona praca nie została potrącona priorytetowo, a dotarcie do wypłaty za poprzedni wysiłek utrzymuje ją wystarczająco wysoko na liście, aby kontynuować pracę. Wiem, że niektóre sklepy tego nie robią, ale większość miejsc, w których pracowałem, uważa zakończenie prawie niedokończonego zadania za zbyt cenne, aby można je było kontynuować, chyba że coś zmieni się dramatycznie. Kara za zmianę kontekstu często nie jest warta zmiany kolejności.

Biorąc pod uwagę, że przenoszona przez nas historia użytkownika jest częściowo ukończona, jak oceniamy ją poprawnie w następnej sesji planowania sprintu?

Nie sądzę, aby opcje od A do C były dobre, głównie dlatego, że (moim zdaniem) najważniejsza w odniesieniu do prędkości zespołu jest średnia prędkość, a nie to, czy prędkość danego sprintu rosła czy spadała.

Kiedy historia użytkownika jest zdefiniowana, powinna mieć kryteria akceptacji. Jeśli cokolwiek w kryteriach akceptacji nie zostanie zrobione, zespół po prostu nie zdobędzie żadnego z punktów. Jeśli historia jest skończona (tj. Zakodowana, przetestowana i zaakceptowana przez PO), zespół otrzymuje wszystkie punkty.

Działa to dobrze, gdy zespół skupia się na swojej średniej prędkości, a nie na prędkości danego sprintu.

Podobnie jak M. Cohn w swojej książce, preferuję scenariusz „wszystko albo nic”. W końcu próba oszacowania, czy osiągnąłeś 5 punktów z 8-punktowej historii, a może tylko 6 lub 7 kończy się kolejną grą w zgadywanie ... i nie zapomnij, że masz już początkową oszacuj daleko. Prawdopodobnie lepiej jest wybrać najprostszą metodę i zdobyć wszystkie punkty po jej zakończeniu.

Cytując M. Cohna z jego książki¹ (moje podkreślenie):

Generalnie popieram podejście „wszystko albo nic” w stosunku do prędkości liczenia: jeśli historia jest skończona (zakodowana, przetestowana i zaakceptowana przez właściciela produktu), zespół zarabia wszystkie punkty, ale jeśli coś w tej historii nie jest nie skończone, nic nie zarabiają. Pod koniec iteracji jest to najłatwiejszy do oceny przypadek: jeśli wszystko zostanie zrobione, zdobywają wszystkie punkty; jeśli czegoś brakuje, nie otrzymują punktów. Jeśli zespół prawdopodobnie przejmie pozostałą część historii w następnej iteracji, działa to dobrze. Ich prędkość w pierwszej iteracji jest nieco niższa niż oczekiwano, ponieważ nie otrzymali uznania za częściowe ukończenie historii. Jednak w drugiej iteracji ich prędkość będzie większa niż się spodziewano, ponieważ zdobędą wszystkie punkty, nawet jeśli pewne prace zostały ukończone przed rozpoczęciem iteracji.Działa to dobrze, o ile wszyscy pamiętają, że najbardziej interesuje nas średnia prędkość zespołu w czasie, a nie to, czy prędkość podskoczyła w górę, czy w dół w danej iteracji.

¹ Zwinne oszacowanie i planowanie , ponowne oszacowanie częściowo ukończonych historii, s. 66

Mój zespół starał się wcześniej przyznać częściowe punkty, pomimo pewnych zastrzeżeń, i nie sądzę, żeby to działało dobrze. (Nie rób tego więcej ... domyśl) Jest to szczególnie przypadku, ponieważ historie mają szacuje się jako zespół , ale jeśli tylko jedna osoba pracuje na nim, to będzie trudniejsze dla zespołu do wiedzieć, ile osoba faktycznie ukończyła. Zwinny bardziej interesuje się średnią prędkością zespołu niż tym, jak „ładnie” wygląda dany sprint.

Mając na uwadze powyższe, autor nie wspomina, że przypisanie częściowych punktów może być uznane, jeżeli zespół jest mało prawdopodobne, aby zmierzyć się z pozostałych prac w następnej iteracji. W takim przypadku zespół oszacuje pozostałą pracę i podzieli ją na nowe historie użytkowników, bez względu na ich rozmiar. Jak wspomina autor²:

Połączone szacunki nie musiałyby być równe pierwotnemu szacunkowi ...

² Ditto, str. 66

Lepszą rekomendacją dla zespołu jest podzielenie historii na wystarczająco mały rozmiar, aby uniknąć tego rodzaju problemów3:

Jednak dwa najlepsze rozwiązania w przydzielaniu punktów za niekompletne historie to nie mieć żadnych niekompletnych historii i używać wystarczająco małych opowieści, aby częściowe uznanie nie stanowiło problemu.

³ Ditto, s. 67

Mam nadzieję że to pomoże.

Dziwię się, że wydaje się, że nie ma na to prostej odpowiedzi. Spodziewałem się refrenu „opcji D, manekina”!

Ponieważ wydaje się, że nie umknęło nam nic oczywistego, doszliśmy do wniosku, że jest to jedna z tych decyzji, które każdy zespół musi podjąć dla siebie w oparciu o to, jak chce pracować i jakie wskaźniki są dla niego najważniejsze.

Zdecydowaliśmy, że prowadzenie dokładnych zapisów wdrożonych przez nas historii użytkowników jest niezbędne, ponieważ stanowią one podstawę naszych testów, dokumentacji wsparcia i informacji o wydaniu - wyklucza to opcję B.

Następnie doszliśmy do wniosku, że umiejętność dokładnego planowania sprintu była niezbędna - co wyklucza opcję C.

Stwierdziliśmy zatem, że opcja A jest dla nas odpowiednia. Ponownie oszacujemy punkty opowieści dla wszystkich opowieści, które częściowo ukończymy w sprincie, abyśmy mogli odpowiednio je zaplanować w kolejnych sprintach. Z czasem zaległości produktowe będą nieco zaniżać liczbę punktów historii, które wdrożyliśmy, ale będzie to mniejszy problem niż jakakolwiek inna opcja i może być rozwiązany poprzez zmianę naszej dokumentacji i raportowania.

Śledzimy czas spędzony na iteracji sprintu dla celów wielkich liter (godziny spalone na zadaniach związanych z historią użytkownika) i przenosimy wskazaną historię użytkownika, jeśli celem PO jest kontynuowanie ciężarówki podczas następnego sprintu, pozostawiając wskazuje to samo.

Jeśli celem PO jest przeniesienie czegoś innego na swoje miejsce, po prostu umieścilibyśmy niedokończoną historię w zaległości i robiliśmy, co chcieli. Pozostawianie oryginalnej oceny punktów jest moją rekomendacją, ponieważ jeśli miałbyś zwyczaj odgryźć więcej, niż mógłbyś przeżuć, przy każdym sprincie, „uzupełniałeś” punkty historii w sprincie, który nie został w pełni ukończony i czysty - testowane przedmioty.

Jeśli chciałbyś zostawić coś w sprincie, wskazać lub musiałeś wysłać, pomyślałbym, że określisz punkt odcięcia w oryginalnej historii, do której osiągnąłeś punkt końcowy, i przekażesz ten mniejszy kawałek dla twojej iteracji. Następnie resztę można ponownie skierować i upuścić w zaległości. To byłaby okazja do ponownej oceny, ponieważ zgodziłeś się ze swoim zespołem podzielić historię na części.

Pierwsze pytanie, które należy zadać, to: Co oznacza punkt fabularny? Jeśli zdefiniujesz punkt fabularny jako „Ile pracy inżynierskiej wykonano”, to zrobi to dowolna odpowiedź. Jeśli jednak zdefiniujesz punkt fabularny jako „Ile wartości jest dostarczana firmie”, ważne jest, aby nie udzielać kredytu, dopóki historia nie zostanie w 100% ukończona, zaakceptowana i dostarczona w 100%. Modyfikacja punktów opowieści po sprincie na podstawie tego, co zostało ukończone, ukryje tylko prawdziwy problem: a) nie było jasnego zrozumienia historii, b) historia była zbyt surowo zdefiniowana, c) opowieść nie miała mierzalnych kryteriów akceptacji, d ) niezbyt głębokie zrozumienie zadań lub zależności do ukończenia historii, e) zaniżono wysiłek przetestowania historii, f) zlikwidowano zbyt wiele punktów historii lub g) ... wstaw tutaj swój powód ...

Celem zwinności jest elastyczność, a jednocześnie przewidywalność. Moim zdaniem najlepszym sposobem na zachowanie spójności jest ustalenie, co poszło nie tak, bez modyfikowania oryginalnych szacunków.