Co zrobić z oszacowaniem niepełnej historii?

Należę do zespołu programistów, który jest stosunkowo nowy Scrum, przypuśćmy, że pod koniec sprintu kilka dużych historii jest in progresslub nie było acceptedprzez PO.

Po pierwsze, co dzieje się z historiami użytkowników? Czy po prostu przenosisz je na kolejny sprint?

Jeśli tak, czy należy je ponownie oszacować? Moim zdaniem praca nad tymi historiami użytkowników może być minimalna czy duża? Jeśli nie, dlaczego nie?

EDYCJA: W moim konkretnym przypadku historie nie zostały ukończone z powodu przeszkody, która trwała kilka dni, a nie z powodu niedoszacowania historii użytkownika. Dla tych z Was, którzy mogą pomóc, korzystamyVersionOne

agile scrum

— ediblecode
źródło

Pracuję z procesem XP, i zastanawiał się, co jest najlepszym sposobem radzenia sobie z tego rodzaju sytuacji

— chrisbunney

Brak identyfikacji przeszkody jako możliwego ryzyka i ustalenia narażenia na ryzyko RE (prawdopodobieństwo * wpływu) wskazuje na problem z oszacowaniem. Historia użytkownika o wysokiej RE wymaga powiązania z nią większego bufora kosztów i czasu, aby poradzić sobie z tymi zagrożeniami, jeśli staną się one problemami.

— Thomas Owens

podwaj go i dodaj 32, podobnie jak C => F

— Paul

Odpowiedzi:

Po pierwsze, co dzieje się z historiami użytkowników? Czy po prostu przenosisz je na kolejny sprint?

To zależy. Jeśli żadna inna historia nie ma wyższego priorytetu, to tak, są one przenoszone do następnego sprintu. Jeśli inne historie mają wyższy priorytet, mogą zostać przeniesione z powrotem do rejestru produktów, jeśli w sprincie nie ma wystarczająco dużo miejsca, aby je pomieścić. Wszystko to dzieje się podczas planowania sprintu, w oparciu o priorytety przypisane do każdej historii przez właściciela produktu. Ponieważ jednym z celów zwinnych metod, takich jak Scrum, jest maksymalizacja dostarczanej wartości przy jednoczesnym skróceniu czasu, wszystko sprowadza się do tego, ile wartości dodanej przynosi zakończenie tych historii.

Niezależnie od tego, co się stanie, nadal musisz dążyć do potencjalnie nadającego się do wysyłki produktu na końcu sprintu. Może to oznaczać wycofanie się, aby upewnić się, że produkt na koniec sprintu przejdzie wszystkie testy, a ukończone funkcje będą w pełni użyteczne przez użytkownika bez znaczących problemów.

Jeśli tak, czy należy je ponownie oszacować? Moim zdaniem praca nad tymi historiami użytkowników może być minimalna czy duża? Jeśli nie, dlaczego nie?

Nie przeprowadzałbym ponownej oceny, ponieważ w Scrumie oceniasz historię, gdy ją akceptujesz, zaczynasz pracę i nie masz pojęcia częściowej kompletności . Historia jest w 100% kompletna, przetestowana i zaakceptowana (zrobiona) lub nie została ukończona. Jeśli nie ma koncepcji częściowego ukończenia, nie ma sposobu, aby określić, ile pracy pozostało w historii. Wygląda na to , że nie jestem też sam w tej myśli . Oszacowałeś pracę, którą według ciebie możesz wykonać, więc zostaw ten punkt danych i spraw, aby omówić, dlaczego oszacowanie nie było w twoim pośmiertnym sprincie, i staraj się unikać tego błędu w przypadku przyszłych sprintów.

— Thomas Owens
źródło

Doświadczyliśmy tego tylko raz i nie miało to związku z błędnym oszacowaniem, mieliśmy pewną przeszkodę, która spowodowała wykonanie pracy, ale nie została przetestowana.

— ediblecode

@ user1016253 Oznacza to, że Twój szacunek miał problem. Szacunki powinny obejmować ekspozycję na ryzyko (wpływ * prawdopodobieństwo = ekspozycja, gdzie ekspozycja ma wpływ na koszt, czas i jakość). Ponieważ pojawiła się przeszkoda, ale oszacowanie nie uwzględniało jej (lub nie uwzględniało jej wystarczającej ilości), coś zostało przeoczone lub źle ocenione (wpływ lub prawdopodobieństwo było zbyt małe, co oznacza, że narażenie było zbyt niski, co oznacza, że nie przydzielono wystarczającej ilości zasobów do zidentyfikowania i rozwiązania problemu, gdy się on zdarzył).

— Thomas Owens

@ user1016253 A jeśli masz problemy z oszacowaniem i dostrzeżeniem ryzyka i potencjalnych przeszkód, być może dobrym pomysłem byłoby rozłożenie historii na wiele historii, z których każda trafia do zaległości lub pod-historii do wykorzystania przez zespół programistów, aby zrozumieć praca, którą należy wykonać. Często łatwiej jest oszacować i przeprowadzić analizę ryzyka w mniejszej jednostce pracy.

— Thomas Owens

@Thomas Owens: To nie wydaje się być użytecznym sposobem zarządzania ryzykiem dla mnie. W szczególności zdarzeniem o niskim prawdopodobieństwie, które nie jest katastrofalne, jest niska ekspozycja, a zatem nawet dobrze zarządzany projekt może być czasami wyrzucany z harmonogramu. Jeśli nigdy nie podejmiesz ryzyka, osiągniesz bardzo niewiele. Oczywiście śledzenie szacunków musi unikać przyjmowania takich wymówek, w przeciwnym razie skończycie z szacunkami, które są tak samo ważne, jak inwestycje, które doprowadziły do ostatniej krachu hipotecznego, i z tych samych powodów

— David Thornley

@DavidThornley To wcale nie jest sposób zarządzania ryzykiem, ale punkt wyjścia do planu zarządzania ryzykiem, który obejmowałby również strategie wykrywania i ograniczania ryzyka. Jest to technika stosowana w celu zapewnienia, że masz wystarczająco dużo pieniędzy i czasu w swoim planie, jeśli ryzyko przerodzi się w problemy. Jest popierany przez Steve McConnell w Software Estimation i Karl Wiegers w tym artykule . Ważne jest, aby zdawać sobie sprawę, że nie jest to bufor dla poszczególnych zadań, ale bufor projektu (lub iteracji), jeśli zmaterializują się różne zagrożenia.

— Thomas Owens

Zazwyczaj wybór mistrza Scrum należy do decyzji, co ma się stać z zadaniami, które przekroczyły sprint, oczywiście po konsultacji z resztą zespołu i sponsorem projektu / właścicielem produktu. Po zakończeniu sprintu nadszedł czas na sprawdzenie, jakie są priorytety. Możliwe, że historia, o której mowa, ma mniejszy priorytet niż nowa / istniejąca historia i należy ją ponownie umieścić w module śledzącym jako „trwającą” lub dowolną etykietą używaną przez moduł śledzący, wskazując, że ta historia ma być kontynuowana w innym miejscu w samą porę. Alternatywnie historia może zostać całkowicie opisana. Nie wspomniałeś o tym, z którego trackera korzystasz, ale większość z tych, które widziałem, pozwala ustawić historię na „opisaną”, jeśli nie jest już częścią projektu.

Po drugie, ponieważ Twój zespół jest nowy w Scrumie, jest to część procesu uczenia się. Teraz wiesz, że niektóre historie są zbyt duże, więc Twój zespół poświęci więcej czasu na ich opowiadanie. Zazwyczaj zadaniem mistrza scrum jest upewnienie się, że tak się stanie. Scrum master będzie musiał również skonsultować się ze sponsorem projektu / właścicielem produktu z niekompletnymi historiami, aby spróbować je dalej rozbić lub uzyskać ostateczny głos na temat całkowitego ich usunięcia.

W moim zespole nowy mistrz Scrum jest wybierany co 2 tygodnie (sprint), więc wszyscy mają szansę na zarządzanie zadaniami, organizowanie spotkań Scrum i upewnianie się, że wszyscy przesyłają raporty z postępu. Mam nadzieję, że tak jest w przypadku własnego zespołu, to z pewnością dobre doświadczenie.

— Desolate Planet
źródło

Nitpick: Decyzja o tym, co zrobić z niepełną historią, jest kwestią ustalenia priorytetów. Dlatego uważam, że powinien zdecydować o tym właściciel produktu, a nie mistrz Scrum.

— sleske

@sleske - Uzgodnione. Powinienem był to wyjaśnić w mojej odpowiedzi. Początkowo powiedziałem, że mistrz scrumowy skonsultuje się z zespołem, ale powinienem był dołączyć sponser / właściciela projektu, który poprawiłem. Dzięki za głowę.

— Desolate Planet

Jeśli niekompletne historie nadal są niekompletne pod koniec sprintu, nie możesz ich naprawdę rozbić w tym momencie, ponieważ prawdopodobnie całkowicie podważy to definicję ukończenia - „Więc mówisz, że ta część historii jest ukończona? Ale nie został jeszcze sprawdzony kod! ” To dlatego epopeje jako pojedyncze opowieści są okropne i nigdy nie powinny być dopuszczane do sprintu.

— Robin Green,

@RobinGreen Zgadzam się z twoim podejściem do eposów i nie jestem ich fanem. Jedną z kluczowych rzeczy (coś, z czym wiele osób pracuje, przeoczyć) jest wartość retrospekcji. Niedawno zaczęliśmy korzystać z tablicy Agile JIRA i często pokazuję zespołowi wykres spalania wyników zespołów. Niekompletne historie są omawiane, jeśli i kiedy się zdarzają, i natychmiast wracają do zaległości. W retrospekcji przyglądamy się, dlaczego historia była niepełna. Brak środków? Brak wiedzy? a może luźna kombinacja tych dwóch.

— Desolate Planet,