#007 – Cel Sprintu

Formułowanie Celu Sprintu dla niektórych zespołów to kłopotliwy moment – robione to jest byle jak, cel nie jest żadnym celem tylko zakresem sprintu a czasem tego celu zespoły nie ustalają wcale, robiąc jak co sprint jakiś zestaw zadań wybranych z Backlogu Produktu. Na życzenie Przemka, jednego z naszych słuchaczy, pochylamy się nad tematem Celu Sprintu i definiując go wyjaśniamy jakie są korzyści z tej praktyki. W drugiej części odcinka eksplorujemy najczęstsze pułapki wraz z propozycjami ścieżki postępowania, które mogą pomóc Tobie i Twojemu zespołowi definiować lepsze cele co sprint.

Jeśli odcinek Ci się podobał, koniecznie podziel się nim z innymi osobami, które Twoim zdaniem mogą go potrzebować. Jeśli masz jakieś problemy z wykorzystaniem podejścia zwinnego albo dręczy Cię praktyczne pytanie z sytuacjami, jakie napotykasz w swoim działaniu jako Scrum Master, Product Owner albo Agile Coach – zachęcamy Cię, żeby wzorem Przemka dać nam znać, możemy poświęcić temat kolejnych odcinków w całości na praktyczne kwestie interesujące naszych słuchaczy.

Daj nam znać co sądzisz o samym odcinku:

Czujne ucho może wychwycić pewną różnicę jakościową w tym odcinku, będziemy na ten temat jeszcze szerzej komunikować. Chcemy usprawniać podcast z każdym kolejnym odcinkiem, więc podpowiedz nam, jakie niedoskonałości Twoim zdaniem powinniśmy poprawić.


4 Replies to “#007 – Cel Sprintu”

  1. Przemek

    Świetny odcinek! Dzięki Panowie!

    Niestety, albo i stety, Wasze odpowiedzi potwierdziły moje przypuszczenia, że problem mojego zespołu odnośnie ustalenia celu sprintu nie wynika z braku wiedzy czy doświadczenia, ale przyczynia się do tego głównie „kształt” backloga i taki brak decyzji ze strony PO (żaba + młotek). Nie wiedziałem nawet, że istnieje tyle anty-wzorców i że można je tak fajnie nazwać 🙂 Smutne jest to, że sam jako Scrum Master (początkujący) obserwowałem i obserwuję wiele z wystąpień tych anty-wzorców. Smutne jest też to, że czasami odpowiedzią na jeden antywzorzec np. „brak celu” jest przejście w inny np. „wielo-cel”.

    Na szczęście zaraz po opisie anty-wzorca zadajecie pytanie: „jak sobie z tym radzić”! Dzięki! 🙂 Daje to nową perspektywę i rzuca inne światło na próbę rozwiązania problemu.

    Do tej pory rzadko słuchałem podcastów. Od czasu jak znalazłem Wasz to codziennie w drodze „do” i „z” pracy w słuchawkach leci podcast 🙂

    Jeśli nie macie jeszcze sprecyzowanego pomysłu na kolejny odcinek, to myślę, że bardzo spoko opcją i nawiązaniem do dzisiejszego odcinka byłby „backlog produktu”. Jak sobie z nim radzić? Co zrobić kiedy do backlogu wszyscy dorzucają „jak łopatą” skoro Scrum Guide jasno mówi że backlog leży w obowiązku PO i tylko on (bądź wyznaczony do tego pomocnik) mogą nim (backlogiem) zarządzać? Jak sobie radzić z backlogiem na 1000 itemów – kiedy wiemy, że nie jesteśmy w stanie przerobić tego nawet w X lat, a co tydzień dochodzą nowe? Czy są jakieś techniki refinementu? Np. ze swojej strony mogę powiedzieć, że jestem już mega zmęczony takim spotkaniem z cyklu: odpalamy jirę, lecimy od góry po niewyestymowanych, każdy czyta sobie acceptance criteria i potem na trzy-cztery rzucamy liczbę. Co więcej z naszych estymat nie wynika ile jesteśmy w stanie dostarczyć przez następne X sprintów bo wyestymowanych zadań mamy co najwyżej na sprint do przodu. Tak mała ilość wyestymowanych zadań wynika z tego, że na refinemencie toczą się nierzadko dyskusje techniczne (jak dany item zaimplementować). Wracając jeszcze na chwilę do tego backloga na 1000 itemów…na jednym ze szkoleń poradzono mi – usunąć te 1000 itemów i zacząć na nowo, od rzeczywistych oczekiwań biznesu. Czy poradzilibyście to samo?

    Jest jeszcze kwestia szacowania w dłuższej perspektywie np. kwartału i półrocza. Co zrobić kiedy przychodzi PO, rzuca roadmapę i oczekuje estymat? Na dodatku w punktach? Czy nie podpada to też w jakiś antywzorzec? Czy jeśli estymujemy jak najmniejsze elementy backlogu to estymata dużych np. epiców, które dodatkowo nie są jeszcze sprecyzowane – ma jakiś sens?

    Dodatkowo – czy istnieją techniki dotyczące podziału zadań? Jakie wg. Was są najlepsze – najlepiej sprawdzały się w Waszych zespołach? Czy możecie polecić jakąś literaturę na temat szeroko pojętego zarządzania backlogiem?

    Jeśli nie odcinek to może odpowiedź na komentarz ? 🙂 Będę bardzo wdzięczny.

    Trzymam kciuki za dalszy rozwój kanału i z przyjemnością udostępniam odcinek 🙂

    • Kuba

      Przemek, rzeczy o które pytasz, w dobrze zniuansowanej odpowiedzi zapewniłyby pewnie z 3 odcinki i nadal by było mało. Trudno też sensownie rozpisać się na te pytania. Mogę obiecać jedno, co częściowo rozpocznie odpowiadanie na Twoje wyzwania – kolejny odcinek już jest nagrany i opowiemy w nim o dobrym podejściu do Refinementu Backlogu. Kolejne wątki w przyszłości…

  2. Robert

    Bardzo trafny i jasno opisany kontent!
    Podpinam się pod kolege z komentarza powyżej odnośnie dobrych praktyk Product Backlogu i ewentualnego wrzucenia w następnym odcinku. Pozdrawiam 🙂

Dodaj komentarz

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