#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.

Zobacz wersję wideo

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ć.

Transkrypcja odcinka:

Jacek: W dzisiejszym odcinku skupimy się na zagadnieniu Celu Sprintu. Jest to temat, który podsunął nam nasz słuchacz Przemek, który napisał do nas takiego Tweeta. Zapytaliśmy o to, o czym konkretnie by posłuchał i dostaliśmy taką informację: „Cel Sprintu, to jest dla mnie jeszcze taka mała zagadka. Często postrzegane jako dowiezienie ticketów, które mają najwyższe prioryty, a to nie do końca tak jest. Czy może być kilka celów dla większego zespołu i temu podobne? Słuchałbym :)”. Tak więc dzisiejszy odcinek poświęcimy w całości na temat „Cel Sprintu” i rozpoczniemy od definicji, co to jest Cel Sprintu, potem porozmawiamy o tym, co nam daje Cel Sprintu, zastanowimy się też, czym tak naprawdę… co chcemy osiągać, definiując Cele Sprintu i zastanowimy się też na koniec trochę, jakie są najczęstsze problemy z definiowaniem Celu Sprintu i podpowiemy, jak sobie z nimi poradzić.

Kuba: Gdybyś miał, Jacek, powiedzieć, co to jest Cel Sprintu, to jak byś to zdefiniował?

Jacek: Tak zupełnie nie szukając definicji wynikającej z „Przewodnika po Scrumie”, powiedziałbym, że Cel Sprintu to jest efekt, który chcemy osiągnąć poprzez pracę, którą wykonamy w Sprincie. I zwykle jest to efekt biznesowy, związany z tym, jaki budujemy produkt i co tak naprawdę byśmy chcieli na tym konkretnym etapie rozwoju produktu, w którym się znajdujemy, osiągnąć.

Kuba: I rozumiem, że ten efekt to też jest, w pewnym sensie, nowy kształt Przyrostu? Jakby… nowa wersja Przyrostu?

Jacek: Kolejny Przyrost produktu tak naprawdę.

Kuba: Pytam dlatego, że tak ja sam Cel Sprintu nie do końca umiem zdefiniować w taki prosty sposób podręcznikowy, natomiast jak mam go tłumaczyć, to zawsze zaczynam od tego, że dla mnie to jest właśnie w pewnym sensie kolejna wersja produktu. Jeśli produkt rozwijamy w jakiś taki sposób sensowny, zdyscyplinowany, mamy jakiś plan jego rozwoju, to każdy kolejny etap, każdy jego kolejny krok w rozwoju prawdopodobnie da się jakoś nazwać, nazwać to jakąś etykietą, jakimś etapem, krokiem, kolejną wersją. I ta kolejna wersja, kolejny krok, to najprawdopodobniej jest kandydat na dobry Cel Sprintu lub część z tego celu.

Jacek: Przychodzą mi do głowy co najmniej dwa powody, dla których warto taki Cel Sprintu definiować. Pierwszy powód jest takim powodem czysto biznesowym, wynikającym z tego, że dobrze by było generalnie, gdyby zespół rozumiał, po co tak naprawdę wykonujemy tą konkretną pracę w Sprincie. I nie chodzi tutaj o to, że mamy do zrobienia pięć zadań, siedem zadań, dwadzieścia pięć błędów do naprawy, tylko żeby Cel Sprintu wyjaśniał, czego my się spodziewamy z takiej perspektywy biznesowej. Czyli, innymi słowy, dlaczego tak naprawdę wykonujemy ten konkretny Przyrost produktu, co jest spodziewanym efektem naszej pracy – takim „uzyskiem”? I to, powiedziałbym, że jest taki aspekt biznesowy, dający kontekst, dający też takie zrozumienie „po co” wykonujemy pracę – takie nadanie trochę sensu. Natomiast drugi aspekt, z mojej perspektywy bardzo istotny, jest taki, że Cel Sprintu dobrze zdefiniowany może wpłynąć na to, że zespół będzie pracował razem, jako zespół, nad realizacją tego konkretnego celu. Natomiast, alternatywnie, mógłby po prostu rozdzielić między sobą zadania, no i po prostu każdy indywidualnie robiłby swojego taska, swoje zadanie, swój błąd – cokolwiek. Natomiast zwykle kończy się to tym, że każdy bierze swoje zadanie, wykonuje pracę, kończy – no i brakuje tego takiego… „kleju” – czegoś, co tak naprawdę spina całą tą naszą pracę, żeby ona dała jakiś taki konkretny, wymierny efekt.

Kuba: I coś, na co warto zwrócić uwagę, to niuans, który jest zawarty w „Przewodniku po Scrumie”, że Cel Sprintu jest ustalany na Planowaniu i jest on stały na czas trwania Sprintu – w przeciwieństwie do planowanego zakresu. Czyli fajnie ustalony Cel Sprintu, taki jakiś… niepodważalny i nie taki uwspólniony sens tego, co robimy, może nam otworzyć bardzo fajną opcję, bardzo przydatną w takich, no, niekorzystnych obrotach spraw, że wtedy się jakoś tam, nie wiem, pomyliliśmy się, co do estymat, pojawiły się jakieś niekorzystne zjawiska i w środku Sprintu musimy – jako cały zespół – przeplanować swoją pracę, włącznie z tym, że trzeba przemyśleć jeszcze raz zakres i zastanowić się, czy czasami nie mamy czegoś, co z tego zakresu da się obciąć albo zmienić, albo jakoś dosyć mocno przeformułować – i wtedy ten Cel Sprintu staje się tą naszą taką bazą, tym takim punktem odniesienia, jedyną stałą (może poza timebox’em, czyli czasem trwania Sprintu) względem których kombinujemy. Kombinujemy co do zakresu, co do sposobu organizacji, dzielenia się pracą – być może nawet szukamy pomocy poza zespołem, ale ten Cel Sprintu to jest to, czego się trzymamy. Cel Sprintu nas gdzieś tutaj skupia na tym, żeby na koniec Sprintu uzyskać przyrost zgodny z tą definicją, z którą mamy na początku Sprintu.

I to jest często też tak, że takiego fajnego definiowania celu zespoły się uczą – jak w wielu innych miejscach – i to pewnie już nam się zdążyło przewijać przez kilka odcinków, że też czasami to też trochę przewija się w pytaniu Przemka, że niektórzy nadal mogą się z jakimś tematem borykać, Cel Sprintu jest jeszcze jednym przykładem tego, że niektóre zespoły mają trudność z formułowaniem celu albo z tego celu nie są do końca usatysfakcjonowane, bo czują, że to jest albo jakoś sztuczne, albo nie do końca oddaje ten sens, o którym wspomnieliśmy – nie daje tych korzyści, które przed chwilą wspomniałeś, czy ja też wymieniłem, no i to jest jeszcze jeden z tematów, o których warto rozmawiać na Retrospektywie. Zastanowić się, z czego wynika to, że ten Cel Sprintu nam się trudno definiuje i nawet może zastanowić się, patrząc wstecz, czy nawet sformułowane cele nie umielibyśmy – z perspektywy czasu i swojego doświadczenia – sformułować inaczej. Bo coś, co jest moim zdaniem żelaznym motywem związanym z Celami Sprintu, no to takie dosyć znamienne zjawisko, że trudność ze sformułowaniem celu albo praktycznie brak możliwości sformułowania celu, jest objawem zupełnie innego problemu niż znajomość tej konkretnej praktyki scrumowej.

Jacek: No to można płynnie przejść do rozmowy na temat tego, co właśnie może pokazywać nam ta nieumiejętność zdefiniowania Celu Sprintu. To, z czym bardzo często się spotykam, pracując z zespołami, to sytuacja, w której te cele bądź nie są w ogóle definiowane, bądź są definiowane w sposób taki bardzo ogólny – coś na zasadzie: koniec planningu, ktoś przypadkowo zapytał: „A jaki jest Cel Sprintu?”. No to jak już zapytał, no to dosłownie w dziesięć sekund pada jakaś tam nazwa, zwykle śmieszna, zwykle niemająca właściwie żadnej… nazwa niebędąca w żaden sposób wskazówką biznesową. Jak jest Wigilia, to nazwa jest „bigos”, jak jest Wielkanoc, to jakaś taka nazwa wielkanocna – i po prostu zwykle te nazwy są śmiesznym tekstem, który wypełnia jakieś tam pole w Jirze. I to zupełnie nie o to chodzi.

Kuba: Czasem też łatwo od takiej dziesięciosekundowej odpowiedzi stwierdzić, że celem Sprintu jest pierwszy „Product Backlog Item od góry” – i to jest cel Sprintu.

Jacek: [śmiech] Tak, zakładając, że ten, co jest na górze akurat jest tym najważniejszym.

Kuba: Tak.

Jacek: Natomiast taka głębsza obserwacja, która jakiś czas temu przyszła mi do głowy, jest taka, że – taka pewna korelacja, którą dostrzegam – zwykle w zespołach, które nie mają celu Sprintu, bądź mają problemy z jego zdefiniowaniem, zwykle kiedy się spojrzy na backlog produktu, no to okazuje się, że po prostu on nie jest przygotowany – ten backlog nie wyraża żadnej sensownej wizji rozwoju produktu. No stąd tak naprawdę – skoro to losowość i przypadek decyduje o tym, czym się zajmujemy, no to po prostu ten Cel Sprintu to jest jakaś taka… no, to, co aktualnie jest – w sumie trudno to nazwać, bo to często są jakieś tam elementy backlogu, każdy dotyczy czegoś innego po prostu, nie wyraża to żadnej sensownej myśli biznesowej, no i jeśli ten backlog jest w takim stanie, no to zwykle te Cele Sprintu po prostu są miałkie, bądź tak naprawdę po prostu jest ich brak.

Kuba: Innym przykładem bardzo podobnej korelacji i też czasem przeze mnie spotykane to to, że trudno ustalić Cel Sprintu, bo Product Owner niewystarczająco spriorytetyzował to, co jest ważne i zespół realizuje jednocześnie kilka idei w ramach tego samego Sprintu. Tu trochę poprawiają user interface, tu trochę poprawiają bezpieczeństwo, tu dodają feature, tu usuwają bugi, tu jakieś drobne usprawnienie technologiczne i tak naprawdę od Sasa do lasa wszystkiego po trochu. I, owszem, może nawet i jest pomysł na rozwój i rozpisane są te epicki, natomiast Product Owner zdecydował w trakcie planowania, że „dziubniemy” po trochu z każdego epicka – i tutaj metafora jednego z trenerów, że produkt jest rozwijany stylem „żaby uderzonej młotkiem”, czyli rozpryskuje się we wszystkich możliwych kierunkach.

Jacek: Ale to dobrze, bo wszystko jest ważne na pewno.

Kuba: No, jest szansa, że gdybyśmy pracowali celami, to też ustaliliśmy jeden cel, na nim się skupili i go zrealizowali, co wraca do tego wątku, o którym wspominałeś, że korzyścią Celu Sprintu jest możliwość pracy całym zespołem – brak tego celu, być może skorelowane ze słabym Backlogiem, wiąże się z tym, że łatwo wpaść nam w antywzorzec, że tak naprawdę, no, towarzyszymy sobie w trakcie Sprintu, ale każdy z członków zespołu realizuje bardzo różne zadania i ściskamy mocno kciuki, żeby na koniec Sprintu to się złożyło w całość. „Udo się albo się nie udo”.

Jacek: [śmiech] Jasne. Jak mówisz o Celu Sprintu, to jeszcze teraz przyszła mi do głowy taka myśl, że Cel Sprintu daje zespołowi bardzo fajną wolność – o tym chyba nie wspomnieliśmy co do implementacji tego konkretnego celu. I nawet jeżeli mamy jakieś ograniczenie czasowe, czy to jest tygodniowy Sprint, czy dwutygodniowy – a z takimi spotykam się najczęściej, no to Cel Sprintu w pewnym sensie popycha zespół w stronę tego, żeby bardzo dobrze się zastanowić nad tym, jakiej wielkości, jakiej jakości – w sensie: jak dobrze odwzorowany będzie ten Przyrost. Czy mamy dużo czasu i możemy się skupić na takim bardzo detalicznym, kompletnym, ostatecznym rozwiązaniu czy nadal możemy zrealizować nasz Cel Sprintu, ale w tydzień, tylko w tydzień, rezygnując z wielu różnych aspektów, rezygnując z głębi odwzorowania produktu, ale tak, żeby nadal na koniec na Przeglądzie Sprintu mieć zrealizowany cel i używalny, działający Przyrost Produktu.

Kuba: A z innej perspektywy – najprostsza wersja, jaka spełnia ten cel i jest realizowalna w zadanym czasie, a nie ta najbardziej rozbuchana, wyidealizowana, co znowu wraca do pracy nad Product Backlogiem – w tym przypadku konkretnie dekompozycji, gdzie no, dobry cel często będzie wynikał raczej z tego, że sobie mocno porozmawiamy, jakie są w ogóle opcje rozwojowe i każda kolejna z tych opcji może też stać się celem, czyli jakaś być może wysublimowana wersja maximum to jest Cel Sprintu nr 4, który dopiero nas czeka, a w międzyczasie mamy wersję pierwszą superminimalną bez feature’ów, druga wersja z jakimiś tam podstawowymi feature’ami, trzecia wersja z rozbudowaną i czwarty Sprint z Celem Sprintu – optimum maksimum, jakkolwiek sobie go nazwiemy. Co nas trochę płynnie przesuwa w stronę tego, że istnieje co najmniej kilka – szczególnie wyróżniamy dwa konkretne typy Celów Sprintu – i to może tytułem wstępu, niektórzy porównują sobie Cele Sprintu albo patrzą na przykładowy Cel Sprintu zawarty czy to w jakiejś literaturze, czy w jakichś artykułach i stwierdzają: „No kurczę, ja nie dam rady takiego Celu Sprintu, bo coś tam”. No i to „bo coś tam” to jest często kontekst biznesowy naszego produktu – czy on jest wewnętrzny, zewnętrzny, dla klientów, czy jesteśmy bardziej software house’em, czy bardziej rozwijamy produkt na wewnętrzne potrzeby, a może w ogóle korzystamy ze Scruma do pracy nad rzeczami, które są zupełnie niezwiązane z programowaniem, no i wtedy ten Cel Sprintu będzie mógł mieć bardzo różny kształt – więc tu wraca to, żeby dobrze zdefiniować sobie te podstawy, natomiast ja wyróżniam dwa typy celów. Jeden to taki, nazwę, bardziej feature’owy czy produktowy – że definiujemy Cel Sprintu poprzez jakąś formę prostego zdefiniowania tego ostatecznego produktu, a drugi typ celu, to jest taki cel bardziej skupiony na rezultacie, na jakimś takim celu biznesowym czy wyniku, efekcie biznesowym, który chcemy uzyskać. On będzie mniej konkretny produktowo, ale za to o wiele bardziej ukierunkowany biznesowo.

Jacek:  Wiesz co, tak zaryzykowałem takie stwierdzenie, że można by to było tak stopniować – nie mamy w ogóle Celu Sprintu, mamy taki feature’owy, który mówi dosyć dokładnie, mimo wszystko jednak, co zrobić, no i ten biznesowy, który jest już taki najszerszy, jakby tylko nam mówi, co chcemy uzyskać, no a ta możliwość realizacji i wybór w ogóle, jak to zrealizować, jest po stronie zespołu. I jeśli chodzi o ten cel feature’owy, to to, co lata temu do mnie trafiło, jako taka dobra podpowiedź, która pomaga w zdefiniowaniu takiego Celu Sprintu produktowego, to jest po prostu włączenie czasownika w proces definiowania tego celu. Czyli konstruując podczas Planowania Sprintu cel, zastanawiamy się, jaki czasownik wpleść w formułę Celu Sprintu, żeby jak najlepiej oddać to, co chcemy zrobić, no i takie czasowniki, to: „zrealizować”, „umożliwić”, „dostarczyć”, „pozwolić na…”, czyli takie rzeczy, które wyraźnie wskazują na to, co chcemy zrobić, no i zwykle uzupełniamy to zdanie jakimiś tam bardziej konkretnymi wyrazami, które definiują, że na przykład chcemy pozwolić użytkownikowi zalogować się przy pomocy przy pomocy konta fejsbukowego. Tak więc to jest takie bardzo podejście, w którym ten czasownik w pewnym sensie nas nakierowuje na to, jak ten Cel Sprintu zdefiniować.

Kuba: A dla porównania użyjemy tego twojego przykładu, jakbyś mógł sformułować, czysto hipotetycznie, jak brzmiałby Celu Sprintu zdefiniowany tak biznesowo, rezultatem biznesowym, bo często pułapką jest zatrzymywanie się w tych Celach Sprintu na tym właśnie poziomie produktu: „Zrealizujemy kawałek produktu”. Jakby brzmiał cel biznesowy dla podłączenia możliwości logowania się przez Facebooka?

Jacek: Myślę, że to byłby cel na zasadzie: zwiększenie ilości użytkowników w serwisie. Jakby, myśląc w ten sposób, że to logowanie przez Facebooka może obniżyć barierę wejścia dla niektórych osób, które na przykład, bądź konkretnie nie chcą zakładać nowego konta, bądź po prostu przez wygodę zrobią jedno, dwa kliknięcia i po prostu już będę w serwisie, czyli: bądź jakieś obniżenie bariery wejścia, bądź po prostu jakiś taki taki cel biznesowy związany z akwizycją nowych użytkowników produktu.

Kuba: I ta odpowiedź, którą teraz dałeś, to jest dobre ćwiczenie dla zespołów Scrumowych na Planowaniu czy jeszcze wcześniej na refinemencie – też dosyć trudny temat dla niektórych Product Ownerów, żeby właśnie porozmawiać sobie o tej logice. Chcemy jakiś feature A, żeby osiągnąć rezultat Y i dobra rozmowa może wyjść, gdy zespół powie: „Słuchaj, ale ten rezultat X to my możemy osiągnąć jeszcze inaczej niż realizując feature A, czyli ten, który nam pierwotnie przychodził do głowy. Nie mówię, że to jest zawsze reguła i nie we wszystkich przypadkach trzeba aż tak bardzo meandrować, natomiast, no, czasami warto się nad tym zastanowić, warto tego spróbować i ja ze swojego doświadczenia mogę tylko powiedzieć, że wielokrotnie zaskakujemy się wzajemnie – ja zespoły i zespoły mnie – jak zupełnie nowe odkrycia wychodzą, gdy trochę odrzucimy tą koncepcję, że tak mamy z góry zdefiniowany zakres, z góry wiemy, co jest dobre, z góry znamy te feature’y, te funkcje, te elementy produktu, które chcemy dodać i Sprinty to jest tylko jakaś taka drobna niedogodność, która stoi na drodze między dzisiaj a zrealizowany w całości zakresem produktu zgodnym z wyobrażeniem kogoś tam – Ownera, zespołu, być może jakichś ważny interesariuszy.

Jacek: To, co powiedziałeś pokazuje też jaka duża przepaść może być między zespołem potencjalnie Scrumowym, który – tak jak mówisz – ja bym to nazwał po prostu „realizuje w iteracjach zaplanowany z góry produkt”

Kuba: Albo projekt.

Jacek: Albo projekt, tak, projekt, no. Po to żeby jeszcze produkt… – „a zespołem po drugiej stronie tej osi, który po prostu rozwiązuje problemy biznesowe w timebox’ach, w iteracjach. Myślę, że te rozwiązania na końcu mogą być kompletnie inne, natomiast spodziewałbym się jednak, że ten zespół taki „eksplorujący”, no, może dojść do ciekawszych rezultatów – tak na zasadzie po prostu dokonywania inspekcji i adaptacji tego, co produkuje.

Kuba: Dobra, trochę podefiniowaliśmy, czym jest cel i po co on jest i jakie rozróżniamy przykłady celów, a jakie są antywzorce? Bo o to trochę pytał Przemek, wymieniając jeden z nich czy może być wiele celów dla jednego zespołu, który jest trochę większy?

Jacek: Zaczniemy od tego?

Kuba: No, zacznijmy od wielocelu.

Jacek: Wielocel. Znany i…

Kuba: [śmiech] …pielęgnowany, lubiany.

Jacek: No tak. Doceniane przez przez wiele zespołów… No taki klasyczny wielocel, z którym się spotykam, no to, powiedzmy, zespół nawrzucał sobie do Backlogu Sprintu jakichś zadań, tak jak mówiłeś o tej żabie, czyli, jakby, no, każde to zadanie jest jakby z innej parafii, no i kiedy pada pytanie, przykładowo moje do Product Ownera: „No dobrze, ale jaki jest cel tego Sprintu, co chciałbyś osiągnąć?”, no to sprytni Product Ownerzy wychodzą z tego w ten sposób, że w tym momencie spoglądają na Backlog Produktu i mówią: „No ja bym chciał, żebyście zrobili zadanie A i zadanie B, i zadanie C, i zadanie D. To jest mój cel”. 

Kuba: [śmiech] 

Jacek: Świetny cel, Sherlocku, natomiast problem z tym podejściem jest taki, że, no, to jakby wracając do początku – ani to nie daje zespołowi żadnej odpowiedzi biznesowej, w sumie po co to robimy? No bo powiedzenie „Zróbcie te pięć zadań”, no to niewielka informacja. Druga sprawa jest taka, że, no, nie płynie z tego…

Kuba: Żadna z tych korzyści, nie?

Jacek: Tak naprawdę po prostu zrobienie tych zadań, no, będzie po prostu zrobieniem tych zadań i to… jakby też stoi trochę w sprzeczności z tym, że to to jest tylko na Planowaniu jakaś tam nasza prognoza tego, co my myślimy, że zrobimy, żeby zrealizować Cel Sprintu, a nie odwrotnie, tak więc… No, wielocel, jakby… moim zdaniem jest absolutnie zbędnym artefaktem, bo on po prostu nazywa rzeczywistość, ale w taki sposób, że to… ten cel nic nam nie daje – to nie jest żadna wskazówka, do której moim zdaniem można się odnieść, nie wiem, chociażby na codziennym Scrumie.

Kuba: Tak, wykonujemy pusty rytuał, zwłaszcza jeśli do takiego wielocelu ładujemy po prostu konkretne elementy z zakresu. No to jak celem jest zrealizować wiele elementów zakresu, to to nie jest cel, to jest po prostu „zrealizować wiele elementów zakresu”, nazwijmy to po imieniu. Być może na tym etapie nie jesteśmy wystarczająco gotowi, żeby formułować cel i lepiej tak to nazwać, niż udawać, że wypełniliśmy jakieś pole na jakimś Wiki albo umiemy wpisać coś do jakiegoś maila.

Jacek: Tak.

Kuba: Jakie są jeszcze antywzorce lub może możemy coś z tym zrobić?

Jacek: Z wielocelem? No, pierwsza rzecz, którą możemy zrobić z wielocelem, no to w ogóle, myślę, zaadresować ten problem, że: „zobaczcie” i, jakby, cała ta rozmowa, którą przed chwilą odbyliśmy. To, co często zdarza mi się robić, no to mimo wszystko jednak z tego… szerokiej możliwości tego, co możemy zrealizować, być może jest jednak coś, co z perspektywy biznesowej jest najważniejsze. Potencjalnie da największą wartość albo być może rzecz, którą musimy zrobić, no bo po prostu mamy jakieś ograniczenia wynikające z ustaw czy jakichś tam terminów współpracy z innymi firmami czy klientami i tak dalej. Tak więc mimo wszystko… oczywiście to nie jest rozwiązanie perfekcyjne, ale mimo wszystko wybranie jednej rzeczy i spowodowanie, że, jakby, co by się nie działo, to tak planujmy pracę na co dzień i tak współpracujemy, żeby co najmniej tą jedną rzecz dostarczyć. I to może być taka sytuacja, że, nie wiem, mamy pięć zadań i my robimy tylko to jedno, ale to jedno najważniejsze, dzięki któremu unikamy kary, dzięki któremu integrujemy się z jakimś serwisem, który daje nam ileś tam wzrostu, pieniędzy, nowych użytkowników, no i to jest taki… jak „baby step”, w sensie takie coś bardzo…

Kuba: Tak, mały krok.

Jacek: Mały krok, który możemy zrobić, on nie jest perfekcyjny, ale uważam, że jest lepszy niż tkwienie w tym takim… no, wielocelu, który tak naprawdę nie daje nam nic.

Kuba: Czyli krok we właściwą stronę, który otwiera tam też nam możliwość później porozmawiania sobie o tym, jak mam się sprawdził ten cel, jak się z tym czujemy, jak się czujemy z tym, że to jest raptem bardzo mały kawałek zakresu, że robimy wiele innych rzeczy, które też są ważne ale w ogóle nie istnieją w tym celu. No, to otwiera nową dyskusję, a nie tak trochę przykrywa problem wielocelu.

No może jednak jakie są jeszcze inne antywzorce?

Jacek: No, znanym i lubianym również jest brak celu. Trochę o tym już powiedzieliśmy, no brak celu to jest po prostu sytuacja, w której zespół wybiera jakieś  elementy z Backlogu Produktu, przerzuca je do Backlogu Sprintu, dobrze jeśli przy okazji planuje, jak będzie realizował pracę, natomiast po prostu to się nie zamyka żadnym, jakby, żadnym celem. Po prostu mamy zrobić te „X” tematów, tyle zaplanowaliśmy, no zrobimy wszystko, żeby je zrealizować, natomiast nadal jakby nie wiadomo, gdzie tak naprawdę powinniśmy mieć ten, jakby, punkt, który należy nacisnąć, nie wiemy, jakby, co tak naprawdę z tego wszystkiego jest ważne, no i to jest dla mnie taka praca totalnie bezkontekstowa, w sensie, biorę jakieś zadanie, robię je, oddaję, nie wiem, pomagam komuś, ktoś robi inne, ale tak naprawdę być może gdybyśmy wiedzieli, co jest ważne, co jest celem, no to tą pracę byśmy planowali na Planowaniu zupełnie inaczej, ale co ważne, w trakcie codziennej pracy w Sprincie i w szczególności na codziennych Scrumach, no, bylibyśmy w stanie się odnieść do tego: „Okej, gdzie my jesteśmy w ogóle z tym celem? Czy my ten cel realizujemy? Idziemy w dobrą stronę? Czy kompletnie… robimy dużo pracy i bardzo dużo leci kurzu, ale biznesowo zrobiliśmy nawet jednego małego kroczku w w kierunku tego, co tak naprawdę jest ważne. 

Kuba: No i tutaj z takim brakiem celu, no to do popracowania może być wiele  rzeczy. Mi przychodzi do głowy jednak właśnie to, co już wspomnieliśmy o tej korelacji, że jeśli trudno ustalić cel, to być może mamy problem z Backlogiem i popatrzenie na ten  Backlog czy w ogóle realizujemy Refinement, jak ten Backlog jest ustrukturyzowany, być może kandydatami na Cele Sprintu mogą być epicki, jako takie jakieś grubszego kalibru elementy, które łączą w sobie więcej elementów zakresu rozwoju naszego produktu. Być może do popracowania jest jakaś roadmapa czy wizja rozwoju danego produktu w danym zespole i czasami trzeba wrócić do takich, powiedzmy, podstaw, być może bardziej wysokopoziomowych, być może też z horyzontem czasowym na trzy do sześciu miesięcy wprzód, żebyśmy złapali ten kontekst biznesowy, zrozumieli, jakie cele biznesowe osiągamy, jakie rezultaty mamy osiągnąć, jakie być może feature’y, jeśli patrzymy bardziej perspektywą takich elementów czy funkcji naszego produktu, jakie musimy zrealizować, jakie chcemy zrealizować, jakie ma nasza konkurencja albo jakie my chcemy wprowadzić, żeby naszą konkurencje wyprzedzić. I dopiero gdy sobie przepracujemy ten poziom taki bardzo wysoki, zaczną nam się pojawiać kandydaci na cele – to spośród tych wszystkich funkcji, jakie chcemy zrealizować, która z nich jest ta pierwsza ważna, o którą będziemy walczyć. Spośród wielu wyników biznesowych, jaki wynik biznesowy chcemy zaatakować w pierwszej kolejności i o ile jesteśmy w stanie go zaatakować w ramach bieżącego Sprintu. Tam może być czasami dużo smutnych refleksji o tym, że jesteśmy w stanie naprawdę niewiele zrobić, że ten rezultat biznesowy drgnie tylko o włos. Ale być może, no, jeśli taka jest rzeczywistość, to lepiej sobie odkryjmy szybciej niż później? Wiele zespołów, zwłaszcza z taką, powiedzmy, perspektywą czy z takim skupieniem się na po prostu realizowaniu projektu albo realizowaniu kolejnych, jak to też Przemek użył w tym swoim tickecie, wspomnianym na początku, że po prostu realizujemy tickety, jakieś kolejne zlecenia, kolejne feature’y, kolejne drobne zmiany…

Jacek: Po prostu robimy.

Kuba: To po prostu robimy. Biegniemy w gęstej mgle przed siebie. Ciągle się pojawiają nowe zlecenia, ciągle nowe zamówienia realizujemy, realizujemy, realizujemy – i to nie ma kompletnie żadnego sensu, to się w nic nie spaja.

Jacek: Idąc dalej, mówiliśmy tutaj o braku celu, no to takim pozytywnym potencjalnie przeciwieństwem jest posiadanie tego Celu Sprintu, który jednak ciągnie się przez ileś konkretnych Sprintów z zespołem. To to zwykle wygląda tak, że mamy Planowanie Sprintu: „Jaki jest Cel Sprintu?”. „No, ten sam, co ostatnio”. „A jaki był ostatnio?”. „No, w sumie jest ten sam od pięciu Sprintów”. „A jaki?”. „No, zrobić coś tam i coś tam…”. I to jakby… To, co obserwuję, kiedy ten Sprint ciągnie się z zespołem przez parę Sprintów, że najczęściej, jakby, po pierwsze, ten Cel Sprintu przestał już dawno mieć znaczenie i raczej jest jakby takie tak… Widzę, że zespoły z ulgą przyjmują informację, że „zaklepmy ten sam Cel Sprintu, co był i co jest już tam, powiedzmy, od dwóch miesięcy i będziemy mieć spokój”. A z drugiej strony, to pokazuje, że tak: albo ten cel jest źle zdefiniowany albo zespół nie ma kontekstu biznesowego, albo zespół nie ma wiedzy tak naprawdę, jak ten cel zrealizować. Natomiast takie pytanie, które mi teraz przyszło do głowy, to pytanie powinno brzmieć: „Gdzie jest Product Owner?”. Jeżeli zespół od kilku Sprintów robi cel i to trwa, i trwa, i trwa, i tak naprawdę nie daje to moim zdaniem tej stronie biznesowej, w szczególności, żadnego punktu odniesienia: „No to gdzie my jesteśmy z tym Celem Sprintu? Bo skoro robiliśmy go już pięć Sprintów, no to pytanie, ile jeszcze Sprintów potrzebujemy?”. I zwykle spodziewałbym się, że w takiej sytuacji, jakby, nie spodziewałbym się, że zespół da jakąś taką wiążącą odpowiedź, w stylu: „Na bazie naszej przewidywalności, prędkości, rozmiaru Backlogu, to będzie, no, myślimy, że za dwa-trzy Sprinty”. Zwykle ten taki ciągnący się Cel Sprintu jest po prostu symptomem tego, że bardzo złe rzeczy dzieją się w Backlogu, a właściwie żadne się nie dzieją, przez co zwykle nie ma tej wiedzy, zadania są za duże, nie ma kontaktu biznesowego, no i po prostu jest taki pozorny płaszczyk, że jakieś cele robimy, ale tak naprawdę to jest iluzja, no bo ten cel w ogóle nie jest jakby… on nie jest osiągalny, nie daje też tego fajnego uczucia: „Zrobiliśmy Cel Sprintu, dostarczyliśmy coś, świeci się na zielono, jest rezultat biznesowy”, tylko…

Kuba: „Osiągnęliśmy kolejną bazę na drodze na szczyt”.

Jacek: Tak, robimy.

Kuba: Jak zadajesz trudne pytania, to w tym kejsie też by się przydało pytanie, czy wiemy, na czym polega Przyrostowość. Bo to też jest dosyć klasyczne. To czasem może wynikać z tego… Roztoczyłeś taką opowieść dosyć pesymistyczną. Ja ten antywzorzec też widuję w zespołach, które całkiem nieźle pracują z Backlogiem, ale czegoś brakuje – i to coś, czego brakuje, to sobie… to jest właśnie takie bardziej konkretne dodefiniowanie, na czym polegają kolejne Przyrosty. Zespół, który mierzy się z czymś naprawdę gigantycznym, jakieś, no, nie wiem, wielkie korporacyjne systemy łączące się ze sobą albo, nie wiem, fragment systemu do bankowości – no, to nie są rzeczy, które się da w taki namacalny, wartościowy biznesowo sposób zrobić w tygodniowym Sprincie i siłą rzeczy to zajmie kilka Sprintów, ale to jeszcze nie znaczy, że te kilka kolejnych Sprintów muszą się nazywać „Dodać nową lokatę”, bo to może być: „Dodać nową lokatę w wersji superminimalnej bez corner case’ów”, „Dodać lokatę, ale jeszcze nie na rynek tam inny zagraniczny” i jeszcze „Dodać lokatę i uwzględnić jakieś auto-przedłużania”, czyli kolejne wersje produktu od wersji superbiednej, której z automatu wiemy, że nikt nas nie wdroży, ale już jest całkiem sensownym Przyrostem, no i czasami coś, czego dosłownie brakuje, to ten ten taki… ta „kropka nad i”, czyli nazwanie sobie, czym się różnią się między sobą te kolejne wersje w kolejnych Sprintach. Najpierw miejmy Przyrostowość, a jak już miejmy, to umiejmy nazwać te kolejne Przyrosty, czym się różni między Sprint… Sprint od Sprintu, zwłaszcza jeśli to, czym się one różnią, to będą te punkty cięcia, o których wspominałeś czy… jakiś czas temu… że na przykład na interfejsie nie ma żadnej różnicy, bo cały Sprint poświęciliśmy na lepszą skalowalność tego produktu. No to nazwijmy Sprint: „Dorobić skalowanie produktu X z poziomu 1000 użytkowników realizowane w jednostce czasu do poziomu dwa miliony” albo ileś… 

Spotykam się też czasem z antywzorcem, który też mi się nasunął, jak pytałeś o to, gdzie jest Product Owner. To czasem Product Owner jest i mówi na Planowaniu Sprintu: „Celem Sprintu jest zrealizować cały zakres zaplanowanego Sprintu”.

Jacek: Mhm. [śmiech] Tak, no… To jest taki…

Kuba: Co na to…?

Jacek: Tak… [śmiech]

Kuba: Co na to powiedzieć?

Jacek: Co na to powiedzieć? No, jakby… Co do zasady bardzo bliskie jest mi myślenie w ogóle o Planowaniu Sprintu, że to, co planujemy na Planowaniu to jest taki snapshot, taki jakby… to, co na dzisiaj nam się wydaje, że jest najlepszym sposobem zrealizowania celu albo że to są te rzeczy, które dzisiaj powinniśmy zrobić. Natomiast bardzo często doświadczam sytuacji, w której na skutek rozpoczęcia wykonywania pracy okazuje się, że albo tej pracy będzie więcej do wykonania, albo sposób, który myśleliśmy, że będzie dobry, żeby tą pracę wykonać – nie działa. Albo okazuje się, że pojawiają się jakieś nowe ograniczenia, o których nie wiedzieliśmy – itd. itd. Jakieś nowe zależności… Stąd też, z mojej perspektywy, w szczególności realizując złożone produkty, tak naprawdę my nie jesteśmy w stanie dobrze planować nawet w tak krótkim okresie, jak dwa tygodnie, bo zwykle okazuje się, że złożoność systemu nam na to nie pozwala. Pojawia się niespodzianki i sytuacje, których nie jesteśmy w stanie przewidzieć, stąd założenie, jakby… Cel: „Celem Sprintu ma być zrealizowanie tego, co tu zaplanowaliście” – stoi w sprzeczności z podejściem zwinnym i ze Scrumem, w sensie, jako narzędzia do rozwiązywania złożonych problemów. To jest takie oczekiwanie od ludzi rzeczy niemożliwej.

Kuba: Tak.

Jacek: I, co gorsze, takim smutnym rozwinięciem tego antywzorca jest potem rozliczanie zespołu: „Zrobiliście dziewięć z dziesięciu zadań, no, bardzo ładnie, ale cel nie jest zrealizowany”. „A dlaczego?”. „No bo celem było zrobienie 10/10”. No i w skrajnym przypadku to ta kara, w sensie: „Nie zrobiliście”, no to ona będzie co Sprint, no bo zespół może pracować nad tak złożonym, innowacyjnym, niejasnym produktem, że po prostu nie ma szans, że będziemy trafiać co Sprint z rezultatem, jeśli chodzi o wybrane elementy Backlogu.

Kuba: Albo naturalną reakcją zespołu będzie tej sytuacji wejście w negocjacje, czyli: jak to zrobić, żeby wziąć jak najmniej, żeby podnieść prawdopodobieństwo zrealizowania wszystkiego, co jest w zakresie Celu Sprintu i lądujemy w idiotycznej sytuacji, w której celem Product Ownerem czy priorytetem Product Ownera, pozycją negocjacyjną jest: „Weźcie jak najwięcej”, a pozycją negocjacyjną zespołu jest: „Weźmy jak najmniej”. I wszyscy gubią cel biznesowy, czyli: zróbmy wartość biznesową, zróbmy dobrze użytkownikom, klientom, zrealizujmy jakiś wynik biznesowy.

Jacek: Co być doradził w takiej sytuacji, gdybyś coś takiego spotkał w zespole?

Kuba: To jest chyba największy temat na współpracę między Scrum Masterem a Product Ownerem i ten aspekt edukowania, czym jest Scrum, bo jeśli to Product Owner formułuje w ten sposób cel, a tak w przykładzie to użyłem i tak to czasami spotykam, no to ktoś tu czegoś nie zrozumiał i trzeba sobie usiąść i pogadać, z czego wynika usztywnienie tego zakresu, bo to jest takie mocno, mocno życzeniowe myślenie i próba znalezienia rozwiązania na właśnie złożoność świata, na jego niepewność i magicznie wpisanie czegoś do jakiejś pozycji czy jakiegoś pliku powoduje, że nagle niepewność zamienia się w pewność. [ze śmiechem] Fajna idea, chciałbym tak… Czyli, no, współpraca między Scrum Masterem a Product Ownerem, próba też, no, wielu z tych rzeczy, które wymieniliśmy już do tej pory, bo tak naprawdę „Cel to zrealizować zakres” to praktycznie takie combo wielocelu, braku celu, no i tak naprawdę jak już Owner ze Scrum Masterem, być może cały zespół – bo być może zespoły też mają ten wzorzec już zaszyty i się na to godzą, z jakichś powodów, nawet nieświadomie, jakie to daje im konsekwencje negatywne – no to uświadomić sobie, że problem jest, a potem zrealizować któreś z tych porad, które już wymieniliśmy do tej pory. Popracować nad Backlogiem, popracować nad roadmapą rozwoju produktu, porozmawiać o tym, jakie mamy cele biznesowe, być może porozmawiać o Przyrostowości. Wiele z tych rzeczy, które wymieniliśmy, no, pewnie całkiem otwiera się… otwiera inne możliwości po zrealizowaniu Story Mappingu, który tutaj jest dobrym sposobem na złapanie Przyrostów, na porozmawianie z zespołem o różnych opcjach na zrealizowanie danej funkcji, od tych takich superprostych, najbardziej minimalistycznych, przez pośrednie aż do tych wersji supermaksimum. No i tu, jeśli zespół przejdzie przez takie uświadomienie sobie, że problem jest, pogadanie o tym, jakie są narzędzia do tego, żeby tą Przyrostowość i tą celowość uzyskać, no to jest szansa, że wrócimy do rozmowy z samego początku naszej, tej części o antywzorcach, czyli na początek weźmy jakiś mały kroczek, malutki cel i zobaczmy, jak to nam funkcjonuje i uczmy się w kolejnych Sprintach.

Jacek: Mamy ostatni antywzorzec, jeśli chodzi o Cele Sprintu do omówienia – jest to taki antywzorzec, w którym zakładamy, że Cel musi pokryć cały zakres Sprintu.

Kuba: Nie wiem, czy to jest antywzorzec, ja przede wszystkim bym powiedział, że to jest uproszczenie czy jakieś takie dopowiedzenie sobie czy… no, nie wiem, zła interpretacja tego, co podpowiada Scrum. O to uproszczenie szczególnie łatwo w zespołach, które pracują mocno projektowo i mocno rozwojowo, a takie podejście praktycznie automatycznie staje się niemożliwe w zespołach, które odpowiadają w całości za opiekę nad danym produktem, który ma i trochę pracy rozwojowej, i trochę pracy utrzymaniowej, i jakieś rzeczy związane z długiem – tam automatycznie rzeczy, które wchodzą w zakres Sprintu, no, w dosyć oczywisty sposób nie mogą w całości pokrywać się z Celem Sprintu, są jakieś rzeczy dodatkowe przydatne, ale nie kluczowe biznesowo, są jakieś rzeczy przydatne, ale nie mieszczą się w celu, ale nasz zespół stwierdził, że też spróbuje się tego podjąć. Więc tutaj… głośno nazwijmy to: Cel Sprintu nie musi pokrywać w stu procentach zakresu Sprintu, a pewnych sytuacjach to wręcz może prowadzić do dosyć – nazwę to – niebezpiecznych fiksacji, jak ktoś za bardzo zrozumie, że: „O kurczę, tego zadania to ja w ogóle nie mam prawa tykać, bo jest nie w Celu Sprintu”. I stoi jakaś awaria na produkcji, bo ktoś czegoś nie zrozumiał.

Jacek: Absolutnie, w sensie, Cel Sprintu jest Celem Sprintu i fajnie, żebyśmy po prostu jakoś z głową i w sposób przemyślany rozwiązywali produkt, ale jeżeli oprócz tego pojawiają się jakieś rzeczy, które, no, po prostu musimy zrobić, no to… to je robimy i  spotykam się z takim podejściem, że: „Ale przecież to nie jest Cel Sprintu”. No nie, to nie jest w Celu Sprintu, co nie znaczy, że nie mamy tego zadania czy tej czynności, która jest tam do zrobienia wykonać.

Kuba: Cel Sprintu jest fajnym wyznacznikiem tego priorytetu, fajnym wyznacznikiem tego, na czym zespół się skupia w pierwszej kolejności, ale zwłaszcza jeśli zespół realizuje to, co zamierza, prace przebiegają w dosyć dobry sposób, prognozowany zakres prawdopodobnie uda się zrealizować – nie ma nic złego w tym, żeby rozmawiać też o rzeczach innych, które mogą się przydać z powodów technologicznych, może trochę wyprzedzają już też plany rozwojowe co do produktu i zaczynamy jakieś działania z kolejnych etapów rozwojowych, bo ten, który zrealizowaliśmy, udało się zrealizować. No, takim logicznym, koronnym dla mnie argumentem jest to, że jeśli Cel Sprintu jest zrealizowany wcześniej przez cały zespół – na zasadzie takiej, że: „No, udało się osiągnąć i mamy już wszystko”. No to zespół może dobrać do Sprintu. No i co? Dobrać może ale tylko z celu?

Jacek: Mhm.

Kuba: No nie. Może dobrać w zasadzie w porozumieniu z właścicielem produktu dowolne rzeczy, no i to mogą być rzeczy zupełnie inne niż Cel Sprintu.

Jacek: Dobrze. Podsumowując dzisiejszy odcinek, rozpoczęliśmy od Tweeta Przemka, który zapytał o Cel Sprintu, zdefiniowaliśmy sobie, czym jest Cel Sprintu, jaką wartość daje dla zespołu Cel Sprintu, porozmawialiśmy trochę o tym, jakie możemy mieć rodzaje tego Celu Sprintu i omówiliśmy pokrótce kilka antywzorców, czyli takich najczęściej spotykanych zachowań, które są błędne, są często takim bardzo powierzchownym… Próbą… bardzo powierzchowną próbą zrozumienia tego, czym jest Cel Sprintu, no i domknęliśmy to krótkim rozważaniem na temat tego, czy Cel Sprintu musi pokryć cały zakres Sprintu. I nie musi.

Kuba: Jeśli są jeszcze jakieś tematy, wzorem Przemka, śmiało podsuwajcie je nam – chętnie o nich szerzej opowiemy, więc złapcie nas na Twitterze czy przez inne nasze kanały.

Jacek: I to by było tyle na dzisiaj. Dzięki, Kuba.

Kuba: Dzięki, Jacek.

Jacek: I do usłyszenia…

Kuba i Jacek: …wkrótce.


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 *

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń Podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial