Jak powiedział Dwight D. Eisenhower: “Plan jest niczym, planowanie jest wszystkim”. Jak masz jednak planować, jeżeli nie korzystasz z podstawowych metryk dostępnych w świecie Agile?
Do dzisiejszego odcinka zaprosiliśmy Maćka Wojciechowskiego – Scrum Mastera i Agile Coacha, który jest również wykładowcą SWPS na kierunku User Experience Design/Product Design. Od 6 lat pomaga zespołom i organizacjom zwiększać efektywność i osiągać wyznaczone cele dzięki wprowadzeniu zwinnych praktyk i frameworków pracy.
Maciej wspierał tworzenie szerokiej gamy produktów i usług: systemów CRM, ERP, Data Lake, aplikacji mobilnych, webowych in on-premise. Pracował w różnych organizacjach: od startupów przez softwarehouse’y po międzynarodowe korporacje z różnych branż , jak P&G, Gray Group, Uniper, ViacomCBS czy T-mobile.
Omawiamy najważniejsze metryki, które warto używać do mierzenia efektywności pracy zespołu oraz dobre praktyki, które warto wdrożyć w Twoim zespole.
Z tego odcinka dowiesz się:
- Jakie metryki mamy do dyspozycji w świecie agile?
- Dlaczego warto mierzyć pracę zespołu?
- Czym są Story Pointy i jak ich używać poprawnie?
- Jak mierzyć Velocity oraz Capacity zespołu?
- Jak wycisnąć więcej z narzędzi, które już prawdopodobnie masz do dyspozycji?
i wiele więcej 🙂
Agenda
00:00 – Intro
02:41 – Wywiad z Maciejem Wojciechowskim
03:21 – Jakie metryki mamy dostępne w metodologiach zwinnych?
05:42 – Od jakich metryk należy zacząć kiedy nie nic nie mierzysz?
06:55 – Czym są Story Pointy i jak ich używać?
09:09 – Dlaczego nie porównujemy Story Pointów między różnymi zespołami?
14:12 – Co się stanie jak powiążesz Story Pointy z czasem?
16:13 – Czym są Velocity i Capacity?
19:27 – Wpływ zmian w zespole na wasze metryki
22:59 – Patologie porównywania zespołów na bazie Story Pointów
25:04 – Jak oszacować potrzebny czas pracy?
27:55 – PRO Tip dla użytkowników JIRY – Używaj releasów w złożonych projektach
28:45 – Do czego przyda Ci się wskaźnik capacity?
29:58 – Podsumowanie Story Pointów
30:41 – Co zrobić z punktami kiedy nie zrobimy wszystkiego co planowaliśmy?
35:08 – Czego brakuje na Daily?
36:34 – Velocity vs Commitment
39:56 – Czym jest Sprint Goal?
41:25 – Jak powinno wyglądać dobre User Story?
44:18 – Planowanie i negocjacje z Product Ownerem
45:17 – Przykład definiowania wizji i celu produktu
48:50 – Jedna rzecz, którą możesz zrobić w swoim zespole
49:44 – Podsumowanie
Wersja do słuchania
Linki
- EVIDENCE-BASED MANAGEMENT™ (EBM)
- Kanban przy kawie
- Roman Pichler – Goal oriented Roadmap
- LinkedIn Maćka Wojciechowskiego
Polecam Certyfikowane kurs Scrum.org
- Professional Agile Leadership™ – Evidence-Based Management™
- Professional Scrum Master™
- Professional Scrum Product Owner™
Artykuły dotyczące Story Points:
- What are story points?
- How Do Story Points Relate to Hours?
- Story Points: Why are they better than hours?
Transkrypcja odcinka
[00:00:59.680] – Krzysztof
Cześć, witamy w Nerd Management, tutaj Krzysztof Rakowski i Paweł Rekowski. Czasami pytamy Was naszych słuchaczy i widzów albo naszych znajomych poprzez linkedina, poprzez inne źródła, żeby nam polecili fajnych ciekawych ludzi z którymi moglibyśmy porozmawiać, zwłaszcza na tematy które nas interesują. Jakiś czas temu zapytaliśmy o polecenie specjalistów od Scruma bo chcieliśmy zapytać o kilka ważnych kwestii i dzięki temu udało nam się poznać z Maćkiem Wojciechowskim który… kim jest?
[00:01:34.690] – Paweł
Maciek jest Scrum Masterem i Agile coachem, zajmuje się Agile już od dawna, wspomaga również różne duże firmy, także wiele firm które na pewno znacie on tam maczał swoje palce, żeby procesy poprawić usprawnić przejrzeć.
[00:01:51.020] – Paweł
No i dzisiaj rozmawiamy o metrykach. O tym co warto mierzyć, czego może nie warto mierzyć, co się wydaje, że jest tym co tylko się wydaje. Bo podczas tej rozmowy ja sam się dowiedziałem wielu ciekawych rzeczy, które wydawało mi się że są tak naprawdę zupełnie czymś innym dlatego warto to zobaczyć. A żeby takie fajne materiały jak ten was nie omijiały to tutaj zapisujcie się newsletter i również jeżeli coś chodzi wam po głowie, macie jakieś pytania, to walcie śmiało bo my jesteśmy po to też żeby znaleźć odpowiedzi jeżeli my nie wiemy to znajdziemy takich fajnych ludzi.
[00:02:25.720] – Krzysztof
No to zobaczmy, posłuchajmy tego wywiadu, metryki to jest coś co gdzieś zawsze zostaje na końcu, albo nie wiemy jak je zrobić albo w jaki sposób te metryki wdrożyć u siebie. W związku z tym zapowiada się bardzo ciekawy wywiad. Zapraszamy. Lecimy.
[00:02:41.170] – Paweł
Cześć Maciek, dzięki wielkie, że przyjąłeś zaproszenie do naszego show. Ty się specjalizujesz w metrykach w Scrumie, w Agile. Wielu z naszych widzów to są programiści, testerzy czy ludzie z IT, którzy myślą o stanowiskach liderskich albo świeżo upieczeni liderzy, którzy dopiero awansowali, zastanawiają się, co oni tutaj robią.
[00:03:06.280] – Paweł
I powiedz mi może na początek jakie metryki mamy pracując w metodykach zwinnych. Czyli z reguły to będzie Scrum, może Kanban. I co one tak naprawdę znaczą?
[00:03:21.880] – Maciej
Czyli metryki dotyczące zespołu ,tego jak on performuje jak szybko coś dostarcza. Jak szybko mu idzie praca jak szybko osiąga cele. Czyli w przypadku Scrum najczęściej mówi się o velocity. Najczęściej mówi się o capacity i story pointach. Często też się mówi o człowieko godzinach, człowieko dniach czyli tych mandayach. Tam już sytuacja jest w mojej ocenie trochę gorsza jeżeli ma się z tym styczność.
[00:03:49.030] – Maciej
W przypadku Kanbana mówi się o lead time, cycle time, czy througpucie, często się też wspomina o limicie na Work in Progress. To jest to jest akurat, ta rzecz jest dosyć ciekawa.
[00:04:06.340] – Maciej
No i to są takie główne metryki, z którymi się spotkacie jeżeli chodzi o zespół.
[00:04:13.630] – Maciej
Jeżeli chodzi zaś o produkt no to tam już ROI i wszystkie pochodne. Fajną rzeczą jest takich z takich metryk dotyczących produktu jest Evidence Based Management, znajdziecie link w opisie. Co więcej mówić? Przydatne rzeczy. Przydatne rzeczy.
[00:04:34.870] – Maciej
Jeżeli chcecie świadomie się gdzieś przemieszczać do przodu z czasem, z produktem, rozwijać go, być lepszym w tym co robicie, chcecie żeby ta praca była przyjemniejsza, łatwiejsza, taka bardziej płynna, no to metryki są na pewno na pewno rzeczą, do których warto się zwrócić. Na początku to jest zawsze trudne, każda nowa rzecz na początku jest trudna, ale później te rzeczy już wchodzą tak w krew, mierzenie tego, przyglądanie się temu i czerpanie wiedzy i informacji z tych metryk że po kilku sprintach, kilku tygodniach to się staje po prostu naturalne i pomaga np. w planowaniu, pomaga przy przeglądzie produktu czy przeglądzie sprintu.
[00:05:18.660] – Paweł
To super, to powiedzmy teraz na początek… Mamy ten zestaw metryk i teraz dobrze, jak z nimi zacząć? Załóżmy, że jest sobie zespół który wchodzi w Scruma, gdzieś pojawił się jakiś Product Owner, zaczął zbierać te zadania, układać je i zespół siada do takiego pierwszego refinementu i co się dzieje? Na co powinien zwrócić uwagę?
[00:05:42.700] – Maciej
Najprawdopodobniej gdzieś w takiej okoliczności pojawi się temat story pointów. Czyli trzeba się zastanowić przede wszystkim, należy zbudować taką świadomość czym ten punkt jest a czym nie jest. To pierwsza rzecz. Później trzeba sobie ten backlog porównać ze sobą, tak naprawdę. Najważniejszą chyba rzeczą jest to żeby utrzymać tę praktykę przez… zależnie jak długi macie sprint, ale żeby utrzymać tę praktykę przez powiedzmy 2-3 sprinty, bo do tego momentu to może być trochę problematyczne, bo to jest nowa rzecz, ale w momencie w którym już się to utrzyma, to to po prostu wchodzi w krew, wchodzi w nawyk.
[00:06:19.520] – Maciej
Nie chodzi o to, żeby to było idealne od razu, od pierwszych rzeczy. Żeby wszyscy rozumieli, żeby to była wycena taka 100%. Chodzi raczej o to, żeby żeby zacząć to robić. Im dłużej to się robi tym te wyceny są bardziej trafne, tym zespół lepiej zna swoje możliwości nawzajem, lepiej rozumie wymagania, lepiej rozumie poziom skomplikowania w ogóle w całym projekcie i świadomość rośnie. Więc ważne jest raczej to żeby to zacząć robić, niż żeby to było od razu idealne. Ale też trzeba wiedzieć w którym kierunku pójść.
[00:06:50.420] – Maciej
Na pewno nie ma co wiązać story pointów z czasem. W ogóle teraz taką definicją rzucę, że story point to jest bezwymiarowa jednostka relatywnej wielkości. Czyli trochę może być to skomplikowane, ale tak… Ona jest relatywna, jeżeli mamy trzy wymagania – porównujemy je wobec siebie. Tutaj jest ta relatywność. Coś jest małym wymaganiem, większym, jakimś tam ogromnym. Albo bardzo małym z kolei. Ale tylko wobec siebie można je porównywać.
[00:07:21.620] – Maciej
Czyli nie porównujemy story pointów między zespołami. Nie patrzymy ile punktów zrobił jeden zespół w sprincie dwutygodniowym, a ile zrobił drugi w dwutygodniowym. To jest nieporównywalne. Można to kalibrować na jakimś tam dalszym etapie. Trzeba się zastanowić, czy jest w ogóle z tego jakiś zysk. I to też dotyczy wszystkich metryk w Scrumie. Mierzenie to jest jedna rzecz, druga rzecz trzeba się zastanowić po co nam to jest.
[00:07:48.080] – Maciej
I teraz często też się zdarza, że po prostu coś się mierzy dla samego mierzenia, bo tak się zawsze robiło i później z tą informacją nie do końca wiadomo co zrobić. Nie wiadomo czemu służy ta informacja, ale ktoś w oparciu o nią podejmuje decyzję. I teraz jest pytanie jak dobrą decyzję podejmiemy. Podejmiemy tak dobrą, jak dobre mamy metryki, adekwatne do sytuacji.
[00:08:08.810] – Maciej
Wracając jeszcze do do story pointów. Czyli mamy tę relatywną jednostkę, która tak naprawdę… Co ona opisuje? Ona opisuje coś co po angielsku nazywa się effort, czyli to jest taka wypadkowa… Trochę trzeba o tym wspomnieć, że tam jest pewien element czasu. Coś co jest bardziej skomplikowane w teorii zajmie więcej czasu, coś co jest bardziej żmudne zajmie więcej czasu. Czyli w ilu miejscach trzeba będzie zajrzeć, wprowadzić zmiany, ile kategorii dotkniemy, ile klas, itd itd. Albo jak dużą analizę implementacyjną trzeba wykonać.
[00:08:51.490] – Maciej
Jest tam element, w tym efforcie, complexity czyli takiego poziomu skomplikowania problemu, który staramy się rozwiązać featurem czy czemukolwiek nadajemy te story pointy. I to jest taka wypadkowa.
[00:09:10.310] – Maciej
Dlaczego nie porównujemy tego między między zespołami? Praca którą wykonują developerzy to jest praca kreatywna która nie jest liniowa. Czyli to nie jest tak, że jak będę siedział 4 godziny nad klawiaturą to wyprodukuje na minutę dwie linijki kodu i po czterech godzinach tych linijek kodu będę miał X. Tylko jest tak, że na rozwiązania często wpada się w drodze na zakupy, w trakcie spaceru z psem, gdzieś poza biurkiem, gdzieś poza pracą albo w jakimś zupełnie innym kontekście przy okazji usłyszenia, że ktoś rozwiązał coś podobnego tak i to nam się zaczyna wtedy składać, znajdujemy rozwiązanie, albo po prostu długą analizą. Tutaj nie ma nie ma takiego jasnego przeliczenia na czas.
[00:10:01.070] – Maciej
Właśnie – jak zacząć? Mamy ten backlog, najlepiej jest rozłożyć sobie te wymagania. Takim pierwszym fajnym ćwiczeniem jest to, że sobie rozkładamy te wymagania i rozkładamy od lewej do prawej, od mniejszego do największego. I w ogóle nie zastanawiamy się nad punktami. Tu są te małe, tu są te duże, tam w ogóle na końcu może być jakiś epic, coś wielkiego. I dopiero gdy je sobie rozłożymy i zespół mniej-więcej się zgadza, że to jest taki… Albo inaczej.
[00:10:32.840] – Maciej
I tutaj też przestrzegam programistów szczególnie, bo macie tendencję do takiego bardzo szczegółowego podchodzenia. Na tym etapie trzeba tylko wiedzieć, że to jest bardziej skomplikowane od tego albo albo w drugą stronę. I jeżeli nawet są dwa podobne wymagania, które troszkę się jednak różnią – tam nie ma sensu się zastanawiać. Czy to jest większe czy to jest większe. Ważne, że one są bardziej po tej stronie albo po tej. Bo to jest praca iteracyjna. Wykonujemy najpierw jedno ćwiczenie, za jakiś czas kolejne, dowiadujemy się więcej, dopisujemy szczegóły, Product Owner coś odpowie, rynek coś pokaże, że to jest może ważniejsze. Czyli tych może nie ma sensu wyceniać, itd.
[00:11:14.050] – Maciej
Chodzi też o to, żeby przyłożyć odpowiednią ilość uwagi i pracy w odpowiednim momencie. Takie leanowe trochę Just In Time. I teraz gdy mamy je już rozłożone. Można zrobić dwie rzeczy. Można wziąć małe ale nie najmniejsze i jemu dajemy 5 i duże ale nie największe jemu dajemy 13. I później w ramach tych dwóch punktów odniesienia przydzielamy te punkty całej reszcie. Można też zrobić tak, że wybieramy taki w miarę pośrodku i dajemy mu ósemkę. No i oczywiście mamy tę skalę Fibonacciego, zaczyna się 0 0,5 1 2 3 5 8 13 20 21… 40 80 100 i znak zapytania. I przydzielamy te wielkości.
[00:12:10.570] – Maciej
W trakcie tego przydzielania chodzi o to, żeby była rozmowa, żeby była dyskusja. I teraz te punkty… Znowu, dlaczego ich nie porównujemy? Bo jeden zespół ma inną wiedzę, inne doświadczenie niż inny zespół. Dla niektórych ludzi, nawet w tym samym zespole pewne rzeczy są po prostu łatwiejsze, pewne są trudniejsze. Poziom skomplikowania całego produktu, projektu jest inny.
[00:12:33.100] – Maciej
Ja miałem kiedyś taką sytuację że wycenialiśmy integrację z Facebookiem, chodziło o logowanie. I chłopaki dali – akurat nie było żadnej dziewczyny w zespole – chłopaki dali taki rozstrzał dosyć duży. Ktoś dał znak zapytania, ktoś dał 13, ktoś dał 20, ale dwóch developerów dało jeden i pół. I ten rozstrzygał między tymi estymacjami był takim rozpoczęciem rozmowy co się dzieje. Jaka jest wiedza poszczególnych członków zespołu, jakie oni wcześniej mieli doświadczenia, zanim przyszli do tego zespołu. Kto co robił, kto jest w czym dobry. I z tym featurem akurat stanęło tak, że implementowała go osoba która tam dała jakąś dużą wycenę, z taką pomocą tej osoby która dała tę wycenę niską. Tak, żeby się nauczyć, żeby to było jakieś wyzwanie trochę, żeby z kolei ten deweloper który miał duże doświadczenie się po prostu przy tym nie nudził. Ale żeby było to wsparcie zespołu.
[00:13:40.030] – Maciej
Czy to jest dobrze że oni dali mało czy oni dali dużo? Świetnie. Bo była to okazja do tego żeby porozmawiać. To jest bardzo duży plus story pointów. One facylitują tę rozmowę, bo nagle się okazuje że się nie zgadzamy, że mamy inne w ogóle pojęcie o tym, o ilości pracy, poziomie skomplikowania pracy, którą trzeba wykonać.
[00:14:04.060] – Maciej
Jak zaczniecie sobie wyceniać w story pointach one zaczną mieć dla was znaczenie. Bo to jest też często, tak że ktoś wiąże story pointy z czasem. I np. okazuje się że jeden story point z jakiegoś powodu to jest osiem godzin pracy developera, każdego. Jeżeli zwiążemy to sobie na stałe z czasem okaże się, że w każdym dniu jesteśmy w stanie zrobić określoną liczbę story pointów. Jeżeli dodamy tam jakiegoś developera, no to wracamy do tego klasycznego przykładu project managera, który uważa że 9 kobiet w miesiąc urodzi dziecko. No bo przecież jeden dzień to jest jeden story point, więc wystarczy dorzucić. No oczywiście nie.
[00:14:53.260] – Maciej
Pierwsza podstawowa rzecz: nie wiążcie story pointów z czasem. Jasne zastanawiacie się gdzie trzeba dotknąć tego codebase, co trzeba sprawdzić, gdzie trzeba poszukać, bierzcie ten wymiar czasu, ale ale nie wiążcie go na stałe ze story pointami.
[00:15:11.410] – Paweł
Czyli on jest po to, żeby po prostu porównać jedną rzecz… jabłko do jabłka zobaczyć co jest większe, co jest mniejsze ale związanie to z jakąkolwiek metryką czasową naprawdę mija się z celem.
[00:15:22.140] – Maciej
Tak, można sobie zrobić krzywdę po prostu. W krótkim terminie można można sobie po prostu zrobić krzywdę, w długim to już na pewno. Bo jakiekolwiek wtedy planowanie na trzy miesiące od razu ten czas wam zablokuje. I co więcej – jak sobie zwiążemy to z czasem, to nie ma wyzwania.
[00:15:39.610] – Maciej
Bo też jest tak, że praca ci zawsze zajmie tyle czasu ile na nią przeznaczysz. Jeżeli sobie na opisanie jakiegoś story technicznego przeznaczysz 15 minut, to napiszesz to w 15 minut i zajmiesz się czymś innym. Gdy sobie przeznaczysz trzy godziny, to będziesz to pisał przez trzy godziny. Czy efekt będzie lepszy, gorszy? Ciężko stwierdzić. Najprawdopodobniej 15 minut starczy. Więc wiązanie z czasem – słabo.
[00:16:07.990] – Maciej
Jest jeszcze jedno powiązanie z czasem, mianowicie velocity i capacity. O prędkości zespołu… To jest ważne, żeby powiedzieć: to nie jest część scruma. Scrum Guide ci mówi, że musisz to zmierzyć, musisz wyestymować, musisz się zastanowić, musisz zrobić refinement i tak dalej, ale nie mówi ci czego użyć. I teraz jest tak: jeżeli mamy jeszcze przydatność story pointów. Załóżmy, że mamy tygodniowy albo dwutygodniowy sprint i co sprint dowozimy tych story pointów… Powiedzmy w jednym dowozimy 24 w drugim 32 w trzecim 13 w czwartym ileś tam.
[00:16:46.210] – Maciej
I to też się może wahać i to też jest dobre. Szczególnie na początku bo każda błędna wycena jest jakąś informacją zwrotną dla zespołu. W ogóle cały Agile i Scrum i Kanban mówi ci: zrób coś, zobacz co się dzieje, wyciągnij z tego wnioski, zaimplementuj te wnioski i jedź dalej. Czyli jeżeli przestrzelimy się gdzieś z wycenami i to się często zdarza, że myślimy o jakimś featurze, mówimy że to jest 13, później dochodzi do implementacji, okazuje się że, albo na przykład to są trzy jakieś story i każda z nich ma pięć, albo okazuje się, że to jest że to są dwa story i każda z nich ma trzy. Jak gdzieś tam głębiej w to wejdziemy.
[00:17:27.010] – Maciej
To też jest dobra rzecz. To też jest dobra rzecz, bo to pogłębia naszą wiedzę.
[00:17:32.080] – Maciej
No ale tak mamy ten mamy ten sprint. Każdy sprint, wiemy, zajmuje tyle samo czasu. Jeżeli macie taką sytuację, że czasami co trzeci sprint zajmuje 3 tygodnie, a normalnie zajmuje 2 albo 4 tygodnie, to wpłynie na metryki, i to wam zaciemni obraz tego co się dzieje.
[00:17:49.450] – Maciej
Ale dobra, wracamy jeszcze raz: czyli mamy te sprinty, każdy zajmuje tyle samo czasu, w jednym dostarczamy tyle, w drugim tyle w trzecim tyle. Po jakimś czasie, załóżmy taką dobrą dobrą liczbą sprintów jest 10. Jeżeli zespół pracuje 10 sprintów razem, będzie razem to wyceniał, okaże się że to velocity się w miarę ustabilizuje, poziom przewidywalności jeżeli chodzi o te wyceny wzrośnie. Czyli mniej będzie takich pomyłek, mniej będzie przestrzeleń albo niedoszacowań. Co sprint mniej więcej będziecie dowodzili tyle samo. I to może być tak, że tam co sprint, od czwartego, szóstego sprintu np. to zawsze będzie tam 30-32, czasami się uda zrobić trochę więcej, czasami coś się okaże bardziej skomplikowanego mniej. Ale jeżeli wiemy, że w jednostce czasu załóżmy, że to są dwa tygodnie, dostarczamy około 26 punktów, to to jest nasze velocity. Co oznacza, że jeżeli spojrzymy na backlog, weźmiemy sobie dowolną pozycję, jeżeli wszystkie wyżej są wycenione, to jesteśmy w stanie powiedzieć kiedy my to dostarczymy. Bez zapinania, się że praca nad tym zajmie nam X godzin. Jesteśmy w stanie odpowiedzieć na pytanie „kiedy?”. Z tym, że tę informację dostajemy po prostu ze statystyki, a nie z próby nagięcia rzeczywistości do tego, jak my ją widzimy.
[00:19:14.850] – Paweł
To od razu tutaj zapytam, bo zobacz: jak mamy to velocity, amy średnią z tego… Tutaj ważne, żebyście na początku się w ogóle nie przejmowali tym, że na początku to będzie w lewo, prawo, góra, dół, i będą jakieś wahania. Tak samo warto tutaj wspomnieć, że te metryki trzeba kalibrować przy wszystkich zmianach, typu dochodzi nowy developer, ktoś odchodzi, to to ma wpływ. Nie można ślepo patrzeć, że tutaj mieliśmy taką średnią, no to robimy z tą średnią, a tak naprawdę wszystko się zmieniło.
[00:19:46.700] – Maciej
Tak, jak dochodzi nowy członek znowu trzeba to skalibrować. Bo znowu jest taka sytuacja, że dochodzi nowy człowiek on ma nową wiedzę i dla niego niektóre rzeczy będą łatwiejsze albo trudniejsze. Też takim błędem przy tym, jest ufanie leadowi albo komuś, kto ma jakąś dużą wiedzę domenową. On mówi, że to jest 5 punktów, dobra to będzie 5 punktów, nie wnikamy, on to zrobi. I zapominamy, i później w momencie kiedy ten człowiek odejdzie, zmieni zespół, firmę, tracimy pewne możliwości w zespole.
[00:20:21.520] – Maciej
Ale tak – dojdzie nowy członek, trzeba zwrócić na to uwagę. Tak jak mówisz. Zmieni się, wejdzie nowa technologia. Znowu trzeba zwrócić na to uwagę. Bo się może okazać, że ta technologia jest mniej lub bardziej znana. Pojawi się nowy kwartał, nowe wymagania, jakieś duży epic do zrobienia – to też może na to wpłynąć.
[00:20:40.480] – Maciej
Co więcej story pointy mają taką tendencję do inflacji. Czyli rzeczy stają się po prostu łatwiejsze w projekcie z biegiem czasu. Chociażby z tego powodu, że bardziej to ogarniamy. Więc może się zdarzyć tak ,że po pół roku ten zespół który dowoził zawsze 34 nagle zaczyna dowozić 50. To też jest spoko. Z tym że te story pointy są taką najlepszą informacją dla zespołu. Bo zespół na ich podstawie jest w stanie odpowiedzieć na pytanie, kiedy najprawdopodobniej coś dostarczy. Z taką przewidywalnością co do sprintu, jest w stanie zbadać swoją wiedzę, swoje doświadczenie, to jak jak on sam performuje, co się wydarzyło, co się nie wydarzyło. Czy trzeba wprowadzić jakąś praktykę, czy trzeba więcej refinementu czy mniej. Może dostosować do tego swoje działanie. Może wydać tę informację na zewnątrz. Product Owner wie, jaki ma mniej więcej timeline. Też wie co się dzieje w developmencie.
[00:21:46.210] – Maciej
Komunikowanie tego wyżej, ponad zespół, wiąże się też z różnymi takimi sytuacjami, że ktoś np. będzie chciał porównywać: ten zespół zrobił w ciągu kwartału 180 punktów, a ten zrobił np. 72. Czy to mówi o wartości jaką dostarczyły te zespoły? W żadnym wypadku. Możemy zapchać spring dwudziestoma czterema punktami które dostarczą nam przesunięcie marginesu, zmianę koloru przycisku. Tego typu rzeczy. A możemy w tymi dwudziestoma czterema punktami wprowadzić feature, który sprawi, że rynek zwiększymy udział w rynku. Albo cokolwiek innego. Więcej pieniędzy. Więc ciężko jest to porównywać.
[00:22:37.480] – Maciej
Co więcej jeżeli porównujemy, staramy się porównać to między zespołami, które się składają z innych członków, oni mają inne doświadczenie, pracują może nawet nad czymś innym. To porównywanie jabłek i gruszek albo pomarańczy. Albo jeszcze czegoś bardziej egzotycznego. Nie ma sensu. Nic z tego nie wynika.
[00:22:58.330] – Maciej
Albo też słyszałem o takiej historii – jeden zespół dostarczył 72, drugi dostarczył 60, mniej więcej, no ale ktoś z zespołu który dostarczył 60 zobaczył, że słabo to wygląda, po prostu do każdej wyceny dodali sobie zero i już było 600 story pointów w kwartale. No to to wygląda super.
[00:23:19.450] – Paweł
Właśnie chciałem to powiedzieć, że tak naprawdę warto się odkleić od tej liczby, no bo każdy może też mieć inną skalę. Np. my stosujemy skalę od 1 do 9. Po prostu to sobie dzielimy na takie trzy worki: małe, średnie, duże i w ramach każdego worka od 1 do 3 to są małe-małe, małe-średnie, małe-duże i tak dalej.
[00:23:40.840] – Maciej
Można też w ogóle… Story pointy są sprawdzonym, fajnym przykładem, wymyślonym przez programistów dla programistów w latach 90. I to działa. Ta skala Fibonacciego sprawia, że te rzeczy które są większe widać że one są bardziej skomplikowane. Bo tamta liczba tych punktów rośnie wykładniczo (prawie), więc rzeczy większe są po prostu większe. Ale nic nie stoi na przeszkodzie, a na pewno nie Scrum Guide, żeby sobie wyceniać tak jak mówisz. Małe, średnie i duże. I w ramach tego jeszcze można tam sobie zrobić… Ważne żeby to było wycenione. I nawet jeżeli po tych sześciu-siedmiu sprintach okazuje się że my jesteśmy w stanie zrobić siedem małych i trzy duże, to też nam mówi jak szybko coś dostarczamy. Więc więc ta kwestia estymacji, która jest opisana w Scrum Guide jest spełniona i to nam pozwala pozwala przewidywać różne rzeczy. A co najważniejsze kiedy coś dowieziemy.
[00:24:42.960] – Paweł
To myślę że teraz czas najwyższy zmierzyć się chyba z tym najtrudniejszym tematem. Czyli mamy te story pointy, zwłaszcza jeżeli mamy tam liczby. Bo te liczby się automatycznie przekładają na godziny. I teraz kiedy przychodzi Product Owner czy przychodzi ktoś z biznesu i on się pyta: kiedy? Kiedy to będzie? To co taki zespół może zrobić?
[00:25:05.800] – Maciej
Jest bardzo prosta rzecz, ja wiem że sytuacja którą opisujesz ona potrafi być stresująca, potrafi w różnych organizacjach różnie wyglądać. Ale jeżeli spojrzymy na Scruma, Scrum mówi tak: co sprint dowozimy coś, co jest potencjalnie wypuszczalne na rynek. Powinno być. Jak wygląda praktyka, to już wiecie u was w organizacjach. Ale teraz tak: co sprint, co przegląd powinniśmy pokazać to co zrobiliśmy. I załóżmy, że mamy ten backlog, on jest wyceniony. Przychodzi Product Owner albo ktoś z biznesu i się pyta: tu jest taki feature, synchronizacja kalendarza, kiedy będzie? Wiemy, że w sprincie dystans który pokonujemy to jest powiedzmy 20 story pointów. Najbliższy sprint powiedzmy, że mamy wyceniony. Kolejny sprint też mamy wyceniony. No i pytanie jest teraz gdzie te 3 story pointy synchronizacji kalendarza? I to jest pytanie bardziej do Product Ownera, czy on chce to mieć w tym sprincie czy w kolejnym. Czy może chce mieć inne ważniejsze rzeczy. Jaki jest tego priorytet. Jeżeli to jest tak, że tutaj tego feature, tej synchronizacji z kalendarza my potrzebujemy na tę chwilę, to oczywiście układamy go wyżej w backlogu, wciągamy go do następnego sprintu i jest. Jeżeli to może poczekać i załóżmy, że minęło siedem sprintów, przez siedem sprintów mamy w miarę stałe velocity, w okolicach 20, to możemy sobie przesuwać. Im wyżej to przesuniemy tym szybciej to będzie.
[00:26:41.110] – Maciej
I znowu: porównujemy to do innych feature, które mamy w backlogu. W momencie w którym stwierdzimy że to jest odpowiedni czas, wartość biznesowa jest odpowiednio wysoka i zmieści się to w danym sprincie, w tym sprincie to będzie. Proste.
[00:26:59.520] – Paweł
Tu nie ma co kombinować.
[00:27:00.190] – Maciej
Nie ma. Na początku to jest trudne, bo jest ogromna niepewność. Nie mamy nic wycenionego, nie mamy velocity zespołu, nic nie ma. I są pytania „kiedy?”. W momencie, w którym zaczniemy to wyceniać, zaczniemy to mierzyć – jesteśmy w stanie odpowiedzieć na to pytanie i to jest odpowiedź, która ma duże prawdopodobieństwo.
[00:27:24.820] – Maciej
Idąc dalej, to jest tak, że gdzieś tam mierzy się tę średnią velocity. Mierzy się najmniejszą i największą, bo to zawsze gdzieś tam oscyluje w granicach kilku punktów. I wtedy znowu mamy tę predykcję jeszcze dokładniejszą. W dobrym przypadku, jeżeli utrzymamy to velocity powyżej średniej, to będzie powiedzmy za dwa sprinty, za trzy sprinty, jak utrzymamy taką niską w najmniej optymistycznym momencie, no to będzie za 4-5 sprintów.
[00:27:56.500] – Maciej
Jeżeli korzystacie z Jiry. Koniecznie korzystajcie z releasów i z wersji w Jirze. Nie napychajcie tam za dużo, niech to będzie tam kwartał, pół kwartału, ale grafy, które dostarcza Jira w oparciu o velocity zespołu, które wylicza i alokowanie itemów do wersji, pokazuje wam taki stożek, który mówi wam, że tę wersję skończymy mniej więcej wtedy, jeżeli nic się nie wydarzy. Oczywiście duża część tej wersji musi być wyceniona, zespół musi pracować przy użyciu narzędzia przez jakiś czas, ale w Jirze jest po prostu odpowiedź na to, kiedy my to skończymy.
[00:28:39.070] – Paweł
Czyli jeżeli stosujecie Jirę, to po prostu to tam jest.
[00:28:42.130] – Maciej
Tak. To tam jest, czeka na was.
[00:28:44.270] – Maciej
Jeszcze jest tak, że przy velocity i przy story pointach mówi się często o capacity. Velocity to jest pomiar tego, co się udało zrobić, a capacity to jest takie przewidywanie, że średnio to nam wychodzi tyle. Wobec czego jesteśmy w stanie planować. I załóżmy sobie, że minął kwartał takiej wyceny, patrzymy sobie w narzędzie, któregokolwiek używamy i widzimy że w kwartał zrobiliśmy, powiedzmy że 150 story pointów. Przychodzi planowanie na kolejny kwartał. Wiadomo, jakie mamy capacity i ile mniej więcej jesteśmy w stanie pomieścić. I znowu dajemy informację do reszty organizacji: najprawdopodobniej tyle dowieziemy. To może być mniej, to może być więcej. Ale znowu minie kolejny kwartał i ta pewność rośnie. W jednym dostarczyliśmy 150, w drugim 170 albo 130 w trzecim znowu ileś tam dostarczymy i zacznie nam się to stabilizować. Im dłużej mierzymy, tym mamy lepsze dane, które nam posłużą jako input do podejmowania decyzji, i do kolejnych wycen, do kolejnego mierzenia.
[00:29:58.120] – Maciej
Więc story pointy są super, trzeba tylko wiedzieć czym to jest, a czym nie jest. Nie można tego wiązać z czasem. Trzeba tego używać po prostu, tu nie ma magicznej różdżki i to w dalszym czasie daje naprawdę fajne efekty.
[00:30:13.450] – Paweł
To teraz patrz: mówimy tutaj o czasie, tak naprawdę o liczbie iteracji. Czytając Scrum Guida, tak standardowo, sprint – dwa tygodnie. To od razu mam takie pytanie. Bo wcześniej powiedziałeś o tym, że ktoś ma dwutygodniowe sprinty, ale jakiś sprint może mu potrwać trzy tygodnie. No to jak to jest, z tymi story pointami, które zostają? To się wydłuża ten sprint?
[00:30:41.170] – Maciej
To nie jest prosty temat. Jest kilka kilka podejść do tego. Scrum Guide mówi tak: sprint trwa od tygodnia do czterech tygodni, bo to jest horyzont czasowy powyżej którego nieprzewidywalność rośnie, może się okazać że to, co wprowadzimy za dwa miesiące będzie już niepotrzebne. Więc stąd jest ten górny pułap. Jeżeli chodzi o dolny, to z reguły jest to nie robi się sprintów krótszych niż tydzień, chyba że to są jakieś takie nie wiem że to jest jakiś design sprint albo próba jakiegoś takiego zwarsztatowania, faza discovery, coś takiego.
[00:31:20.300] – Paweł
Brzmi jak hackathon.
[00:31:20.300] – Maciej
Tak i wtedy się zdarza np. na hackathona, czy tego typu warsztatach, że się robi jednodniowe sprinty. Po prostu otwiera się dzień, zamyka się, sprawdza się gdzie się jest. To dosyć wyjątkowa sytuacja.
[00:31:35.810] – Maciej
I Scrum Guide mówi, że ten sprint ma być zawsze taki sam. On ma być zawsze taki sam, żeby można było dokonywać tej kalibracji, żeby ta świadomość tego co jesteśmy w stanie zrobić i przewidywalność dla reszty organizacji rosła.
[00:31:49.670] – Maciej
W momencie w którym zaczniemy robić tak… Jeden sprint będzie trwał dwa tygodnie, kolejny będzie trwał trzy, kolejny bo wypuszczamy tam na produkcję, to zrobimy taki sprint, który nie do końca jest sprintem, tak przez tydzień będziemy mocno testować i będziemy na standby, jakby coś trzeba było zrobić a później znowu zrobimy dwutygodniowy sprint. To w ogóle nie da się tego porównać. Nie da się tego porównać, te informacje są stracone.
[00:32:16.220] – Maciej
Druga rzecz o której wspomniałeś, czyli powiedzmy, że bierzemy do sprintu na planowaniu 30 story pointów, mamy review, zaakceptowanych jest 28 albo 30. Może się okazać, że np. będzie ich 35. Albo 25. To powiem tak: od razu lepiej jest do sprintu naładować mniej i dobrać, niż przeładować to i mieć te spady co sprint. Jeżeli chodzi o wycenę tych rzeczy, które spadły ze sprintu, nie zostały dowiezione. No to bywa różnie. Bo czasami jest tak, że po prostu czegoś się nie zaczyna. I tam jest dalej tych 5 story pointów załóżmy. A czasami jest tak, że coś się zacznie, ale się nie zdąży. Albo np. zacznie się pracować i tam nagle coś wybucha i się okazuje że to nie jest 5 tylko 13, po prostu czegoś nie przewidzieliśmy. Z takich sytuacji trzeba się raczej cieszyć, niż nie. Bo to jest informacja dla nas.
[00:33:12.260] – Maciej
Czy przenosimy czy zmieniamy wycenę, czy nie. Jeżeli wykonaliśmy jakąś część pracy ja byłbym za tym, żeby ponownie wyestymować. Mieliśmy story, które miało 5 punktów. Coś tam rozgrzebaliśmy, powiedzmy że tak na oko dowieźliśmy dwa. Ale one się nie liczą do velocity. Liczy się tylko to, co udało się dowieźć w całości. I do sprintu zostaje nam to story, ale ono już ma tylko trzy punkty. I dużo developerów mówi, że to jest niesprawiedliwe. Mają trochę racji. Bo praca została wykonana, to complexity zostało… gdzieś tam problem jaki został rozwiązany. Ale raczej chodzi o to, żeby to była taka liczba, która mówi o skończonych rzeczach.
[00:33:56.150] – Maciej
I do kolejnego sprintu bierzemy najprawdopodobniej te trzy story pointy. Więc ja jestem za taką metodą. Mówiąc wprost: czasami lepiej jest po prostu czegoś nie zaczynać. Jeżeli widzimy… Bo pamiętajcie też, że daily jest taką aktualizacją planu, który został ułożony na planowaniu. Czyli na jakimś tam etapie my widzimy, że zostały nam trzy dni. Widzimy, że jest duże story do wzięcia. Lepiej jest pogadać z Product Ownerem i powiedzieć mu: słuchaj, nie dowieziemy tego. To jest po prostu za duże. Mamy dwa dni… Możemy to pociąć, możemy z tego coś wyciągnąć, można renegocjować backlog sprintu. Więc może lepiej jest to pociąć, zrobić jakąś część albo np. powiedzieć, że nie zrobimy tego, od tego zaczniemy w przyszłym sprincie, ale ponieważ mamy jeszcze wolne zasoby, weźmiemy jakieś dwa małe story, z tego co co jest na górze backlogu. Wymienimy po prostu. I dalej dowieziemy jakąś wartość. Dalej działamy w zakresie Scruma „by the book”, dalej sobie naliczamy to velocity i wszystko działa.
[00:35:06.470] – Maciej
Bo to jest kolejna rzecz. Często jest tak że ta pętla zwrotna dzienna, która powinna być na daily, czy idziemy zgodnie z planem, który my ustaliliśmy, nie ktoś za nas. Tylko to my stwierdziliśmy, że my to tak, że my to tak zrobimy. Czy to rzeczywiście idzie tak jak przewidywaliśmy? Jeżeli nie idzie, to trzeba to zmienić. Trzeba na to jakoś zareagować. I często się nie reaguje. Często jest też tak, że np. jeżeli są te stare trzy pytania. Często jest to powtarzane no i można usłyszeć czasami taką rzecz, że wczoraj robiłem to, dzisiaj i będę robił to samo i zobaczymy co będę robił jutro. I tak przez trzy dni z rzędu. Ale to już jest też inna rzecz. Dążę raczej do tego, że jeżeli kończy się wam sprint za dwa dni. I wy widzicie co jest w backlogu, widzicie że to są duże rzeczy, może nie ma sensu tego rozgrzebywać, żeby lepiej jest negocjować to z Product Ownerem, wziąć jakieś mniejsze itemy, albo podzielić ten duży, na jakieś takie logiczne części.
[00:36:15.440] – Paweł
Ja bym tutaj widział jeszcze taką rzecz, że wtedy warto, np. jeżeli macie przestrzeń… jeden developer ma przestrzeń, a inni są jeszcze zarobieni, to zamiast brać coś nowego, niech pomoże innym. Bo wtedy też jest lepsza wymiana wiedzy itd. To jest dużo lepsze rozwiązanie niż dobieranie na siłę.
[00:36:34.250] – Paweł
Tak i chciałbym tutaj wrócić do tego velocity, tego co powiedziałeś. Bo to mogło wam uciec, ale to jest mega istotne, że do velocity wchodzi tylko to, co jest skończone. I tutaj warto porozmawiać o czymś takim jak commitment, czyli właśnie to do czego my jesteśmy przekonani, że my to dowieziemy. Bo tak naprawdę jest przyrost. Sprint do tego, żeby dowieźć jakąś wartość, a to z perspektywy biznesu i to warto żebyście sobie wbili do głowy, no jest tak, że albo jest coś skończone, albo nie.
[00:37:08.690] – Maciej
Działa albo nie działa. Nie ma czegoś takiego jak „dev done”. Ja gdy słyszę, że coś jest „dev done”… to znaczy że co jest? Już skończyłem klepać. Ale nawet na przykład kiedyś miałem taką sytuację, że po prostu było „dev down” i tam developerzy… A później tester przychodzi i mówi: ja nie mogę tego odpalić nawet. Jak się okazało, programiści nawet nie sprawdzali czy to działa. Po prostu coś tam zakodowali I tyle.
[00:37:39.290] – Maciej
Ale to co mówisz, ten commitment to jest podstawowa miara sukcesu i efektywności zespołu. Dowożenie celów sprintu. I to jest w ogóle metryka, którą można sobie przyjąć i w sumie należy ją sobie przyjąć: ile sprint goali dowieźliśmy z rzędu. I co się wydarzyło? To jest fajny taki punkt na retro. Ja często proszę deweloperów, żeby ocenili sprint w skali 1-5, 1-7, jak kto woli. I też jest krótka dyskusja o tym, czy dowieźliśmy sprint goal. A jeżeli nie, to co się wydarzyło? I to mogą być różne rzeczy, często niezależne od zespołu. Ale taką najlepszą dla scrumowego zespołu miarą jest to, ile on sprint goali dowiózł. Bo nawet jeżeli te sprint goale nie dają jakichś wartości dla produktu, źle zostały skomponowane backlogi sprintu, no to zespół jednak performuje dobrze, zespół jednak działa, jest w stanie dowieźć to co Product Owner przyniósł.
[00:38:41.840] – Maciej
Jeżeli organizacja nie jest zadowolona z tych sprint goali, które zostały dowiezione, no to jest prosty feedback dla Product Ownera, żeby trochę bardziej zbadał te potrzeby. Ale jest to też informacja, że to co zamierzyliśmy – osiągnęliśmy.
[00:38:59.300] – Maciej
Dla mnie to jest najważniejsza rzecz ale to jest też satysfakcjonujące może się coś udało zrobić. Praca po prostu wtedy przynosi satysfakcję i to jest też ważne bo wszystkie te metody zakładają że ludzie którzy pracują w zespołach chcą robić to co robią tam ich nikt niczego nie zmusza. Praca jest dla nich ciekawa rozwijająca challengująca, jak to się mówi, ale stanowi pewne takie wyzwanie, które na tym tym poziomie fajności. Że to nie jest… trochę nie wiemy co zrobić ale jesteśmy w stanie to odkryć. To jest bardzo nagradzające.
[00:39:34.190] – Maciej
I teraz taka statystyka którą, możemy wyciągnąć, że przez ostatnie dwanaście sprintów dowieźliśmy 9-10 sprint goali, dwóch nam się nie udało i jeden się jeden się okazał niepotrzebny, więc przerwaliśmy sprint. To jest jakaś informacja w ogóle dla dla otoczenia zespołu jak ten zespół działa, na ile on jest ze sobą zgrany. Czy on dowozi potrzeby biznesowe.
[00:39:56.540] – Paweł
To powiedz jeszcze jak rozumiesz sprint goal. Ja sprint rozumiem w ten sposób, że jeżeli mamy sprint, w sprincie mamy pięć tasków, to sprint goal to jest ten jeden najważniejszy, że jeżeli jutro wszyscy wpadną pod autobus, to jeżeli Product Owner dostanie tę jedną rzecz, to firma jest szczęśliwa.
[00:40:15.170] – Maciej
Okej, takie podejście może prowadzić do tego, że po planowaniu wychodzisz i masz sprint goal 1, wspomniana synchronizacja z kalendarzem, 2 wysłanie maila z powiadomieniem, 3 zrobienie czegoś tam. To jest lepsze niż nic, ale nie do końca o to chodzi.
[00:40:41.000] – Maciej
Cel sprintu powinien… i teraz Scrum Guide o tym mówi, cel sprintu powinien się dokładać do celu produktu. A cele produktu powinny się składać na jakąś jego wizję, na jakiś stan docelowy. I raczej trzeba się zastanowić co my chcemy, żeby było w produkcie, jakie nowe możliwości powinny być w tym produkcie i jak on się powinien zmienić po sprincie, niż myśleć czysto przez pryzmat tego, że mogę nacisnąć przycisk i coś wysłać. Bo jak sobie spojrzysz na format user story, on też z tego co widziałem, często pomija się ten trzeci etap czyli potrzebę, którą użytkownik zaspokaja akcją.
[00:41:26.270] – Paweł
To może wymień od początku.
[00:41:29.050] – Maciej
User story, jeżeli nie wiecie jak wygląda, format jest taki: „jako UŻYTKOWNIK chciałbym CZYNNOŚĆ dlatego po to żeby aby KORZYŚĆ która płynie z tej wykonanej akcji dla tego użytkownika. Czyli na przykład: to jest podcast, ten podcast jest jakimś serwisem. To jest typ produktu konkretnie jakaś usługa. I załóżmy, że na potrzeby przykładu wartością, która płynie z tej usługi jest poszerzenie wiedzy odbiorców i dodanie im narzędzi. Załóżmy, że wy macie jakiś backlog swoich rzeczy do zrobienia. Macie powiedzmy miesięczne sprinty. I staracie się rozwijać rozwijać tę usługę którą prowadzicie, wprowadzać nowe elementy być bliżej. Macie też jakieś cele biznesowe.
[00:42:27.010] – Maciej
Więc jak sobie teraz pomyślisz o następnym waszym sprincie miesięcznym teraz czy Twoim celem jest zrobienie X odcinków? Czy Twoim celem jest poszerzenie wiedzy odbiorców? Albo wprowadzenie nowego standardu na rynek? Albo zareklamowanie nowej nowej metody, nowego… Pytanie co jest co jest tutaj celem? Jeżeli spojrzysz sobie na to w taki produktowy sposób, no to twoim celem nie jest nagranie trzech odcinków. I tak samo jest ze sprint goalem. Tutaj celem nie jest wypuszczenie X features, tylko sprawienie że ten produkt będzie bardziej atrakcyjny, że on będzie bliżej wizji którą ma Product Owner, bądź mieć powinien, która spełnia jakiś business capability albo inne potrzeby biznesowe. W ten sposób trzeba podejść do sprint goal.
[00:43:22.330] – Maciej
Mamy powiedzmy, że te trzy ficzery, zastanówmy się co one razem dają? Jak je sobie przytniemy – co się wydarzy? I raczej mówmy o sprint goalach nie przez pryzmat tych features, ale raczej przez pryzmat tych nowych możliwości, pewnej zmiany, którą chcemy uzyskać w produkcie. Każdy ma inny produkt, każdy ma inną usługę, jest inna specyfika itd. Ale on się musi zawsze odnosić do użytkowników, do możliwości a nie do samego feature. Czyli lepszym sprint goalem będzie… teraz ciężko jest mi z coś wymyślić ale np. w oparciu o ten przykład, czyli ten kalendarz, wysłanie notyfikacji… Czemu to służy? Zadanie zadanie kilku takich pytań pomocniczych. Czemu to służy? Co się wydarzy jak to wprowadzimy? I to jest bardziej taka robota trochę Product Ownera, żeby zadać te pytania i porozmawiać o tym z zespołem, ale też trzeba pamiętać że na planowaniu jest ten etap negocjacji. Przychodzi Product Owner, mówi: chciałbym cel sprintu jest taki. A zespół mówi, że musimy wyciąć tutaj ten element bo po prostu jest za duży. Albo trochę go tam tam nagiąć. I to jak my zdefiniujemy ten cel sprintu pokaże nam też na review, czy w ogóle my jesteśmy w stanie zmierzyć, czy to się wydarzyło czy nie.
[00:44:44.040] – Maciej
To jest płynna materia, trochę biznesowa. Wkład Product Ownera jest tutaj ogromny. Ja mogę dalej mówić o tym, że to jest ważna rzecz. To nie jest proste. Ale trzeba po prostu pamiętać, że ten sprint jest przyczepiony do jakiejś roadmapy. Tam jest jakiś cel dla produktu. I ten cel dla produktu to jest raczej poszerzenie puli odbiorców, może inny przykład. Załóżmy, że wprowadzamy nową aplikację z podcastami. Mamy jakąś tam konkurencję, aplikacje które działają od wielu lat. One mają jakieś swoje modele biznesowe, my wpadamy na nowy model biznesowy który to po prostu wszystko zamiecie. I mamy jakąś roadmapę gdzie jest założenie… W ogóle jeżeli chodzi o roadmapy to polecam Pichlera „Goal Oriented Roadmaps”, one są bardzo blisko w tym momencie ze scrumem. I to jest fajny sposób na określanie takich wyższych celi dla produktu i później z nich wyciągania tych sprint goali.
[00:45:54.050] – Maciej
A wracając do przykładu: mamy tę aplikację do podcastów, mamy jakiś tam czas na development wiemy, że w maju będzie dobry moment, żeby z tym wystartować, dużo się będzie działo wtedy, ludzie słuchają więcej podcastów, itd. Układamy sobie tę roadmapę i raczej na samym końcu będzie zdobycie jakiejś bazy użytkowników, zajęcie jakiejś pozycji na rynku, ilość pobrań itd itd. I jak sobie schodzimy z tego bardzo wysokiego poziomu coraz niżej, to się okazuje że np. ilość pobrań będzie się przekładała na user experience. Na załatanie tych wszystkich dziur które mają inne aplikacje. Więc jak tutaj myślimy o tym przykładzie to sprint goalem będzie raczej dostarczenie pewnego… I to znowu jest jakościowe bardzo, ale dostarczenie pewnego nowego doświadczenia dla użytkownika, niż to że on może odsłuchać podcast.
[00:46:58.320] – Maciej
I teraz bardziej bardziej interesuje nas to, jak on może odsłuchać tego podcastu. I jak spojrzymy później jeszcze na backlog, to się okaże, że mamy tam odtworzenie, pobranie, zapisanie, zakolejkowanie, wysłanie, itd. Ale one razem, jak je sobie dodamy, okazuje się że wynik jest jest większy niż suma tych ficzerów. I tu jest ta wartość. Więc cel powinien być skupiony na około wartości którą software dostarcza użytkownikowi, a nie na tym że on może kliknąć „wyślij”.
[00:47:34.170] – Paweł
Czyli tu nie ma relacji 1:1. Cel – story i tak samo jedno story może realizować kilka celów. I stąd się pewnie wzięło to, że tych celów dowieźliśmy kilka. I tak samo na odwrót.
[00:47:46.470] – Maciej
Co więcej, może się okazać że osiągniesz cel sprintu zupełnie innymi ficzerami. W trakcie sprintu okaże się, że tutaj odkryliśmy że w tym 8 punktowym story to coś, tam coś, wyjdzie nowy magazyn branżowy, gdzieś tam się pojawi jakaś informacja z wnętrza organizacji albo zewnątrz, i wyjdzie na to że my ten cel jesteśmy w stanie zrealizować zupełnie inaczej. Nie trzeba wprowadzać tam tego przycisku itd. Ale możemy np. zwiększyć shareowanie materiałów, poprzez to że wprowadzimy ikonkę jakąś gdzieś. I to się okaże sposobem. Ważniejsze jest. To jaką wartość daje ten cel sprintu niż czym to można osiągnąć to można osiągnąć na różne sposoby.
[00:48:35.130] – Paweł
Super, masa wartościowej wiedzy. I teraz jakbyśmy mieli wziąć taką jedną najważniejszą rzecz, z twojej perspektywy, z twojego doświadczenia, od której warto zacząć i którą nawet jutro już można przetestować u siebie w zespole, to co by to było?
[00:48:53.030] – Maciej
Pierwsza rzecz taka podstawowa, to zajrzenie do narzędzia i zobaczenie, co macie. Bo może się okazać, że tam już macie zestaw danych, z których możecie wyciągać wnioski. Wszystkie te metody polegają na tym, że robimy coś, patrzymy jaki jest tego efekt, implementujemy to w nasz proces.
[00:49:14.030] – Maciej
Na ten moment nawet jeżeli nie wyceniacie w story pointach możecie przejrzeć przez zadania, które zostały zrobione i zacząć je porównywać. Możecie np. wyrównywać pewne pewne obszary czasowe. Taką najważniejszą wskazówką jest to, żeby po prostu zacząć. Najgorszą chyba sytuacją jest to, że będziecie się cztery sprinty przygotowywać do tego żeby zacząć wyceniać. Trzeba zacząć to po prostu robić i pamiętać że z czasem będziecie lepsi.
[00:49:44.810] – Paweł
Super. Mamy cały kawał konkretnej konkretnej wiedzy, a ruszyliśmy raptem dopiero podstawowe metryki. Dlatego też jeżeli będziecie chcieli jeszcze odcinek o metrykach stricte kanbanowych czy o EBM, gdzie możemy gadać gadać i gadać, to koniecznie dajcie znać w komentarzach czy chcecie, wtedy się z przyjemnością z Maćkiem spotkamy i omówimy sobie inne tematy.
[00:50:08.270] – Paweł
Gdzie można cię znaleźć, jak ktoś będzie zainteresowany konsultacjami wsparciem i pytaniami?
[00:50:13.520] – Maciej
Na dole jest tutaj jest mail, można też znaleźć na linkedinie, imię nazwisko jest, więc śmiało piszcie maila ewentualnie na linkedinie. Jeżeli chcecie o coś dopytać czy coś skonsultować – śmiało, zapraszam.
[00:50:28.310] – Paweł
Wszystkie linki oczywiście do tego o czym rozmawialiśmy i dużo więcej będzie w notatkach do tego odcinka, także także wchodźcie na stronę https://nerd.mnagement, tam znajdziecie wszystko.