Na samym początku naszej #białkowej kariery medialnej nagraliśmy film o zmianach w Scrum Guide AD 2017. Jedną z modyfikacji było zalecenie, aby najważniejsze usprawnienie z retro umieścić w Backlogu następnego Sprintu. Dlaczego właśnie tam?
Po co jest Backlog Sprintu?
Od pamiętnego pierwszego nagrania minęło sporo czasu, ale ta jedna zmiana nie daje mi spokoju. Po co umieszczać najważniejsze usprawnienie z retro akurat w tym artefakcie? Przecież to nawet nie jest biznesowe wymaganie!
Dla przypomnienia, Backlog Sprintu to ta część Backlogu Produktu, którą Zespół Deweloperski prognozuje, że wykona w przeciągu najbliższego Sprintu. Oczywiście, jest ona także wzbogacona o plan dostarczenia Przyrostu (np. subtaski).
Skąd Zespół Deweloperski wyciąga elementy do realizacji? Z Product Backlogu, gdzie elementy te są ujęte w postaci Product Backlog Itemów. Tam zaś znajdują się wymagania funkcjonalne, niefunkcjonalne, pomysły, błędy… A czy są tam usprawnienia pracy zespołu? Nie ma ich tam!
Skąd więc pochodzą „akcje z retro”, czyli wspomniane usprawnienia? Identyfikujemy je podczas Sprint Retrospective. I na tym moglibyśmy zakończyć dzisiejszy wpis. Bo jak się ma to najważniejsze usprawnienie do zakresu prac, którą nasz Zespół Deweloperski ma do wykonania?
S.M.A.R.T -na akcja
Najważniejsze, zidentyfikowane przez Zespół Deweloperski usprawnienie powinno zostać zapisane w postaci tak zwanej SMART-nej akcji. A więc ma ona być konkretna, mierzalna, możliwa do przydzielenia do jakiejś osoby, realistyczna i ograniczona w czasie. Jeśli chcecie sprawdzić czym co dokładnie znaczy „SMART-na akcja”, sprawdźcie powyższy link.
Wzbogaceni o tą wiedzę, wyobraźmy sobie następującą sytuację – razem z naszym zespołem zaplanowaliśmy się na najbliższą iterację. Wspólnie utworzyliśmy Cel Sprintu i… dodajemy najważniejsze, zidentyfikowane poprzez poprzedniej Retrospektywy usprawnienie. Ale jak ma się ono do Celu Sprintu i do Przyrostu? No i co na to biznes?
Czy taki element Sprint Backlogu powinien zostać oszacowany? Tylko czekać, aż pojawi się nieśmiertelne „Kto za to zapłaci?”
„Specjalny” element backlogu
Usprawnienie, które dodaliśmy jest wymaganiem specjalnym. Mam tu na myśli fakt, że nie będzie ono elementem Przyrostu, który wypracujemy na koniec iteracji. Nie będzie też podlegało oszacowaniu przez zespół. Usprawnienie to nijak ma się też do Celu Sprintu.
Nikt nie mówi nam czy usprawnienie powinno znajdować się na szczycie, czy na samym dole Backlogu Sprintu. Ma się gdzieś tam po prostu znaleźć. Jaki jest uzasadnienie umieszczenia go w planie realizacji najbliższej iteracji?
Wydaje się, że najważniejszym celem jest to, aby Zespół Deweloperski widział i myślał o tym usprawnieniu przez cały czas trwania Sprintu. Umieszczając ten element na liście wymagań, którymi będziemy zajmować się w następnym Sprincie spowoduje, że przeprowadzając np. Daily Scrum, będziemy skazani na porozmawianie również o tym usprawnieniu.
Cel osiągnięty? Oczywiście. Czy dałoby się osiągnąć go inaczej? Moim zdaniem jak najbardziej.
Nie zgadzam się z tym!
Nie zgadzam się z zaproponowanym przez autorów Scrum Guide podejściem z kilku powodów.
Najważniejszy – po prostu tego nie czuję. Rozumiem, że umieszczenie usprawnienia spowoduje nasze skupienie nad jego rozwiązaniem. Z drugiej strony zaś zastanawiam się nad koniecznością umieszczenia tego elementu na liście wymagań. I co na to wszystko nasi interesariusze?
Jestem za 101% transparentnością, ale jak wytłumaczyć biznesowi, że płaci on za to usprawnienie i co ma przesadzenie przysłowiowego Kowalskiego z daleka od okna do zadowolenia klienta?
Nie od dziś widzimy potrzebę i podkreślamy sens utrzymywania listy akcji z poprzednich retro. Po pierwsze, nie wynajdujemy ciągle koła na nowo. Po drugie, każdy członek zespołu może zweryfikować, jaka akcja została do niego przydzielona po ostatnim retro. A jeśli o tym nie pamięta, już w tym rola Scrum Mastera, żeby mu przypomnieć. SM powinien pokazać wagę realizacji akcji po retro jako formy zmiany naszej pracy na lepsze.
Czuję się trochę jak ofiara odpowiedzialności zbiorowej nierealizowania zadań z retro. Skoro (podobno) zespoły o nich zapominały, to teraz w wszystkich Backlogach Sprintu mają się znajdować niebiznesowe wymagania. Ale w miejscach, w których widzieliśmy dobrze przeprowadzone retro, nie było żadnej potrzeby dodatkowego wspierania ich realizacji.
Da się! Trzeba tylko chcieć i definiować naprawdę przydatne usprawnienia. No i pozwolić Scrum Masterowi zadziałać, gdy się nie chce.
A jaki Ty masz stosunek do umieszczania najważniejszego usprawnienia w Backlogu Sprintu? Czy wg Ciebie ma to sens? Zachęcam do komentowania tego postu i podzielenie się swoją opinią!
Łukaszu, przeczytałem z zainteresowaniem, ale co tu dużo mówić – nie zgadzam się. Kilka komentarzy.
1) Piszesz „transparentnosć, ale” 🙂 Jak dla mnie nie powinno być tu żadnego „ale”. Interesariusze mają prawo wiedzieć nad czym zespół pracuje.
2) Jeżeli zespół na retro zdecydował się dokonać jakiejś zmiany, to ta zmiana z pewnością (prędzej czy później) przełoży się na wartość dla interesariuszy. I nie widzę powodu by się z nimi tą wieścią nie podzielić.
3) Jedną z cech zespołu scrumowego ma być odwaga. No to bądźmy odważniu, podejmujmy trudne dyskusje, ścierajmy się.
4) Wygodnie mieć wszystkie taski zespołu w jednym miejscu i dlatego IMHO jak najbardziej powinny znaleźć się na tej samej liście/tablicy co wszystkie inne zadania realizowane w danym sprincie przez zespół.
pozdrawiam!
Tomek
1, 2 i 3 – Rzeczywisty przykład z retro – jedna z osób ma problemy z higieną i chodzi bez butów, demotywuje to innych i im przeszkadza. Czy na pewno chcemy dzielić się tym z Interesariuszami i im pokazywać takie kwiatki? Jeżeli tak, to strzelamy sobie w stopę bo wtedy mamy praktycznie gwarancję, że niektóre tematy nigdy nie będą poruszane na retro.
4 – Jak powyższy task ma się do codziennej pracy w Sprincie?
4a – „Wygodnie mieć wszystkie taski zespołu w jednym miejscu”, to dlaczego autorzy Scruma mówią tylko o wrzuceniu do Sprint Backlogu tylko jednego, najważniejszego usprawnienia, a nie wszystkich? Przyznam się, że ja też tego zalecenia nie czuję.
nie