Skip to content

Scrum w życiu codziennym

Wyobraź sobie, że kupiłeś na rynku pierwotnym nowe mieszkanie. Załatwiłeś wszystkie niezbędne formalności, mieszkanie odebrałeś i jesteś teraz na etapie wykańczania. Znalazłeś ekipę, która będzie wykonywała prace wykończeniowe.

Product Owner

Nie będziesz jednak mieszkał w mieszkaniu sam. Masz rodzinę — żonę i dwójkę dzieci — oraz psa. Mają oni swoje wymagania i oczekiwania, czasem sprzeczne z twoimi albo innych osób. Twoim zadaniem jest tak zarządzać zakresem, budżetem, terminami, aby wszyscy zostali zaspokojeni w maksymalnie możliwy sposób. Będziesz rozmawiał z żoną, dziećmi, pytał ich o zdanie; będziesz rozmawiał z ekipą, słuchał ich sugestii, bo są profesjonalistami i mają doświadczenie w tego typu projektach, ale ostatecznie to ty będziesz podejmował decyzje, bo ostatecznie to ty odpowiadasz przed swoją rodziną. Ty jesteś Właścicielem Produktu (Product Owner), pozostała część twojej rodziny to interesariusze.

Szacowanie i planowanie

Określasz wymagania, zbierasz je w listę — Bakclog Produktu. Ekipa na podstawie tej listy i rozmowy z Tobą szacuje koszt i czas wykonania wszystkich prac. Obie strony dobrze rozumieją, co to znaczy „szacuje”: nie jesteście w stanie w tym momencie określić dokładnych kosztów, bo nie wiecie dokładnie, ile materiałów będzie potrzeba oraz nie znacie aktualnych cen tych materiałów; nie jesteście też w stanie określić dokładnego terminu zakończenia wszystkich prac, bo nie wiecie, ile czasu na jakie materiały trzeba będzie poczekać; nie jesteście też w stanie przewidzieć, ile przeróbek w trakcie prac będzie, ale wiecie z doświadczenia, że na pewno jakieś będą. Na tym etapie planowania zresztą taka dokładna wiedza nie jest ci potrzebna. Chcesz wiedzieć szacunkowo, ile może cię to kosztować i kiedy orientacyjnie będziesz mógł się wprowadzić.

Określony budżet, ustalony termin

Tak się jednak składa, że budżet masz z góry określony i nie możesz wydać więcej niż na to z żoną przeznaczyliście. Również z jakiegoś powodu najpóźniejszy termin wprowadzki jest z góry ustalony. Dlatego listę swoich wymagań układasz w określonej kolejności, żeby w przypadku, kiedy nie będzie możliwe wykonanie wszystkich prac w określonym budżecie i czasie, miałbyś gotowe te pomieszczenia i te elementy wyposażenia, na których tobie i twojej rodzinie zależy najbardziej i żebyście mogli się już wprowadzić.

Monitorowanie postępów prac

Mógłbyś teraz wyposażyć ekipę w środki finansowe na zakup materiałów, projekt aranżacji wnętrza, umówić się z ekipą na konkretny termin i wyjechać z rodziną na dwu-miesięczne wakacje. Po powrocie prawdopodobnie zastałbyś mieszkanie w takim stanie, że żona zapytałaby, gdzie zamierzasz mieszkać przez najbliższe dwa, trzy miesiące, bo ona z dziećmi u swojej mamy.

Twoje zaś relacje z ekipą byłyby uzależnione od tego, jak była sformułowana umowa między wami. Być może nawet byłbyś w stanie udowodnić ekipie, że to oni nie dotrzymali umowy i nie zrobili tego, do czego się zobowiązali i wymóc na ekipie zwrot kosztów poniesionych na zakup materiałów i robocizny albo wynegocjować kolejne miesiące prac już tym razem na ich własny koszt. Mało prawdopodobne. Prędzej okazałoby się, że formalnie jest jednak wszystko zgodnie z wymaganiami (tymi spisanymi) i możesz im skoczyć i kiedy będzie reszta kasy.

Tak czy inaczej byłbyś głęboko w d., bo twoja rodzina już teraz nie miałaby gdzie mieszkać.

Ale jesteś rozsądnym człowiekiem, więc zamiast zostawiać ekipę samopas i wyjeżdżać na wakacje, siedzisz w pobliżu, pod telefonem. Jesteś na każde ich zawołanie, odpowiadasz na każde ich pytanie, a kiedy wymagane są konsultacje z twoją żoną, to ty do niej dzwonisz i ustalasz kolor ścian, a nie obarczasz tym robotników.

Okazuje się, że tych telefonów o doszczegółowienie albo ustalenie czegoś jest wiele i zdajesz sobie sprawę, że tego wszystkiego nie dało się przewidzieć przed rozpoczęciem prac.

Nie prosisz ekipy o raporty o postępie prac telefonicznie i nie pytasz ich przez telefon, czy coś wygląda dobrze. Zamiast tego często zaglądasz do wykańczanego mieszkania i wynik oraz postępy prac oceniasz na bieżąco empirycznie czyli chodząc, oglądając, dotykając i pukając. Przynajmniej raz w tygodniu zabierasz też tam całą swoją rodzinę, żeby oni też zobaczyli, jak zaczyna wyglądać wasze mieszkanie i mogli zgłosić uwagi jak najwcześniej, jak podczas Przeglądu Sprintu (Sprint Review).

Zespół Deweloperski

W trakcie prac nie ingerujesz w prace ekipy. Nie nadzorujesz ich pracy, nie obchodzi cię, o której zaczynają pracę i o której kończą, czy danego dnia są wszyscy w komplecie czy kogoś nie ma i dlaczego. Nie planujesz wykonywania poszczególnych zadań przez poszczególne osoby. Oceniasz natomiast wynik ich pracy jako zespołu, oczekujesz z ich strony profesjonalizmu, uczciwości, rzetelności, pytań z ich strony, kiedy czegoś nie wiedzą, wsparcia z ich strony wiedzą i doświadczeniem, kiedy to ty czegoś nie wiesz, dostępności, kiedy potrzebujesz się z nimi skontaktować, szczerości.

Przed znalezieniem ekipy i rozpoczęciem przygotowań do prac zleciłeś architektowi wnętrz wykonanie projektu aranżacji twojego mieszkania. Projekt przekazałeś później ekipie. Jesteś spokojniejszy, bo doświadczony architekt zadbał o to, żebyś nie popełnił głupich błędów w aranżacji. Ekipa jest zachwycona, bo nie musi o każdy szczegół pytać ciebie i ma też obraz całości.

W trakcie prac jednak okazuje się, że architekt nie przewidział wszystkiego. Pewnych rzeczy nie da się tak zrobić, inne nie mają sensu. O niektórych kwestiach doświadczona ekipa mówi ci od razu, na inne napotykacie dopiero w trakcie prac. Okazuje się, że pewne pomysły, które wydawały ci się dobre na etapie projektowania, przestają się podobać tobie albo twojej żonie, jak już zostaną zrealizowane. Decydujesz się więc na przeróbki, co cię oczywiście dodatkowo kosztuje i wydłuża termin zakończenia prac. Niektóre pomysły musisz też konsultować z architektem, zabiera ci to czas, zwlekasz z decyzjami.

Myślisz wtedy sobie, jakby to było fajnie, gdyby architekt był częścią ekipy, swoje pomysły konsultował z resztą ekipy wcześniej, byłby dostępny dla ekipy w trakcie prac i wspólnie pracowali nad takimi rozwiązaniami, które spełniałyby wymagania twoje i twojej rodziny, byłyby fajne architektonicznie, realne do zrealizowania oraz optymalne pod względem kosztów i czasu potrzebnego na wykonanie.

Zmiana wymagań

Okazuje się, że zmian w trakcie prac jest tak wiele, że zaczynasz się obawiać o dotrzymanie terminu i zmieszczenie się budżecie. Cieszysz się jednak, że o ryzyku niepowodzenia wiesz już dwa tygodnie po rozpoczęciu prac i możesz zareagować. Teraz jeszcze możesz zrobić wiele: przesunąć termin, zwiększyć budżet, namówić żonę na tańsze kafelki, zostawić wykończenie twojego gabinetu na następny rok. Albo wstrzymać wszystko i nie tracić więcej pieniędzy na coś, co z góry jest skazane na niepowodzenie. Ostatecznie, jeśli nie jesteś zadowolony ze współpracy z daną ekipą, możesz ją zwolnić i poszukać innej. Jest to jednak ostateczność i prawdopodobnie siadasz z ekipą i wymyślacie optymalne wyjście z danej sytuacji i najczęściej takie wyjście udaje się znaleźć.

To zdroworozsądkowe podejście do życia, w którym nie jesteśmy w stanie przewidzieć przyszłości. Nie nazywasz tego Scrumem, ale stosujesz go na co dzień.

Categories: Scrum.

Professional Scrum Product Owner

Dwa lata po szkoleniu Scrum in Depth miałem okazję wziąć udział w szkoleniu Professional Scrum Product Owner z Kenem Schwaberem.

Bogdan Baraszkiewicz i Ken Schwaber w Amsterdamie, 2012

Ja i Ken Schwaber w Amsterdamie, 2012

Szkolenie skierowane do osób odpowiedzialnych za optymalizację wartości dostarczanej w postaci produktów i usług, w szczególności do menedżerów produktów, programów lub projektów, menedżerów działów IT, osób pełniących rolę Właściciela Produktu w Scrumie (Product Owner).

Ja, chociaż nie zajmuję się zarządzaniem produktami, w swojej codziennej pracy pracuję z takimi osobami i jako Scrum Master potrzebuję wiedzy, która może być dla nich przydatna.

Jest to nowy (2011) program szkoleniowy, który skupia się na tym, jak Scrum może pomóc w uzyskaniu zwinności w zarządzaniu produktami i obejmuje m.in. następujące zagadnienia: zarządzanie produktem przy użyciu wartości, zwinne zarządzanie produktem, zarządzanie wymaganiami, planowanie wydań, planowanie w ujęciu lean.

Główne wnioski, jakie się zapamiętały

  • Właściciel Produktu (PO) odpowiada za optymalizację dostarczanej wartości;
  • żeby mógł to robić, musi być jedynym punktem odpowiedzialności (Single Point of Accountability) i mieć ostateczne słowo;
  • warto tworzyć metryki (KPI), aby mierzyć dostarczaną wartość, ale należy zadbać, żeby metryki rzeczywiście odzwierciedlały wartość i być ostrożnym z ich interpretacją;
  • PO zarządza Backlogiem Produktu, ale praca nad jego elementami (PBI) to wspólna praca całego Zespołu Scrumowego (tzw. backlog grooming);
  • Przegląd Sprintu (Sprint Review) to sesja robocza, nie „demo”;
  • zwinność (agility) wymaga podejścia empirycznego, tj. częstej inspekcji i adaptacji, czego warunkiem jest przejrzystość, która z kolei wymaga zaufania i odwagi;
  • dobry PO stawia na współpracę i bezpośrednią rozmowę z Zespołem Deweloperskim, a nie zleca prace w postaci pisemnej.

Kilka cytatów z notatek

O wartości:

Raczej optymalizacja wartości niż maksymalizacja. Maksymalizacja ma wydźwięk ilościowy, optymalizacja — jakościowy.

Upewnij się, że metryki odzwierciadlają wartość.

O zespole:

Myśl o zespole jak o dodatkowej grupie umysłów, nie tylko jak o pracownikach.

Rozmowa z zespołem jest tym, gdzie tworzysz wartość.

O Scrum Masterze:

To trudna praca. Jego [Scrum Mastera] zadaniem jest pomoc ludziom bez mówienia im, co mają robić.

Po szkoleniu podszedłem do testu, który udało mi się pomyślnie zdać i uzyskać certyfikat Professional Scrum Product Owner I.

Categories: Product Owner, Scrum.

Product Owner czy pełniący obowiązki?

Formując Zespół Scrumowy organizacje często stają przed pytaniem, kto powinien pełnić rolę Właściciela Produktu (Product Owner) w danym projekcie lub produkcie. I nierzadko napotykają problem próbując odpowiedzieć na to pytanie.

Dzieje się tak głównie z dwóch przyczyn:

  1. Problem z identyfikacją osoby odpowiedzialnej za produkt

    O ile zazwyczaj jest wiele osób chcących mieć wpływ na kształt produktu, mających dużo do powiedzenia (a nawet do zarzucenia), o tyle czasem ze świecą szukać osoby chcącej wziąć na siebie pełną odpowiedzialność za produkt.

  2. Błędne rozumienie roli Właściciela Produktu

    Rola Właściciela Produktu jest błędnie kojarzona tylko i wyłącznie z pisaniem historyjek użytkownika, określaniem kryteriów akceptacyjnych i spotkaniami z zespołem, żeby zagrać w planning pokera. Więc nawet jeśli znajdzie się osoba, która przyjmie na siebie pełną odpowiedzialność za produkt (np. menedżer produktu), to unika ona pełnienia tej roli, bo jest zbyt zajęta ważniejszymi sprawami związanymi z rozwojem produktu i uważa, że nie będzie czasu na obowiązki Właściciela Produktu.

W rezultacie rolę Właściciela Produktu powierza się np. analitykowi, który ma zbierać wymagania od tzw. „komitetu sterującego” i spisywać je w postaci historyjek lub też reprezentować rzeczywistego menedżera produktu przed zespołem.

Osobie takiej nie daje się wystarczających uprawnień, żeby efektywnie pełnić rolę Właściciela Produktu, ma ona bardzo ograniczoną decyzyjność i służy w zasadzie jako kurier między zespołem a osobami rzeczywiście odpowiedzialnymi za produkt. Zamiast prawdziwego Właściciela Produktu (PO) mamy więc pełniącego obowiązki — p.o. PO.

Jeden głos czy komitet?

  • Prawdziwy PO w Scrumie jest to jedna osoba, jeden silny głos. To zmotywowana osoba z wizją produktu, która, owszem, słucha innych, ale podejmuje ostateczne decyzje.
  • p.o. PO natomiast często jest tylko głosem „komitetu sterującego”, którego członkowie mają często sprzeczne wizje i interesy. Wypracowywanie za każdym razem kompromisów wymaga dużo czasu, a ostateczne decyzje będące próbą pogodzenia sprzecznych ze sobą interesów nierzadko bywają szkodliwe dla produktu i jego użytkowników.

Menedżer produktu czy proxy?

  • Prawdziwy PO jest menedżerem, który zarządza rozwojem produktu. Posiada on wizję, którą może skutecznie komunikować zespołowi dzięki bliskiemu z nim kontaktowi. Wyznacza cel i motywuje zespół do osiągnięcia tego celu.
  • p.o. PO jest jedynie „proxy” komunikacyjnym między menedżerem produktu a deweloperami, w dodatku często nieumyślnie wypaczającym przekazywane komunikaty (efekt głuchego telefonu).

Samodzielność czy przekazywanie decyzji?

  • Prawdziwy PO jest samodzielny i decyzyjny.
  • p.o. PO każdą ważniejszą decyzję musi konsultować z menedżerem produktu, co wydłuża czas oczekiwania przez zespół na odpowiedź. Nawet jeśli p.o. PO wywalczy sobie większą autonomię i będzie próbował samodzielnie podejmować decyzje np. w mniej krytycznych obszarach, to i tak często te decyzje mogą być później podważane i zmieniane przez menedżera produktu.

    Dodatkowo, jeśli nie ma wyznaczonej jednej odpowiedzialnej osoby za produkt w postaci menedżera produktu, a taki p.o. PO ma do czynienia z „komitetem sterującym”, to czas oczekiwania na decyzje wydłuża się jeszcze bardziej.

Zarządzanie czy utrzymywanie Backlogu Produktu?

  • Prawdziwy PO zarządza Backlogiem Produktu, tj. podejmuje decyzje, które mają swoje odzwierciedlenie w brzmieniu poszczególnych elementów backlogu (np. historyjek użytkownika) oraz w ich kolejności w backlogu.
  • p.o. PO jedynie utrzymuje Backlog Produktu, tj. aktualizuje dokument pod dyktando menedżera produktu.

Współpraca czy zlecanie?

  • Prawdziwy PO zdając sobie sprawę ze wszelkich ograniczeń i czynników ryzyka współpracuje blisko z zespołem i szuka wspólnie optymalnego sposobu na osiągnięcie celu.
  • p.o. PO natomiast będąc jedynie „proxy” i mając nikły wpływ na cokolwiek zazwyczaj tylko zleca i wymaga, bo motywuje go wywiązanie się z zobowiązań danych menedżerowi produktu lub komitetowi, a nie sukces produktu.

Tak więc taki p.o. PO problem rozwiązuje tylko z pozoru. Owszem, jest jedynym punktem kontaktu dla deweloperów, ale taki punkt kontaktu nie jest ani decyzyjny, ani samodzielny, nie komunikuje skutecznie wizji, nie wyznacza celów, nie zarządza rozwojem produktu, wydłuża ścieżkę komunikacyjną zamiast ją skracać, a postawiony między młotem (klient/menedżer produktu) a kowadłem (deweloperzy) chroni przede wszystkim siebie zamiast dbać o sukces produktu.

Cierpią na tym wszyscy: zespół, menedżer produktu czy klient, produkt, końcowi użytkownicy i w rezultacie cała organizacja. I oczywiście analityk, któremu powierzono tę niewdzięczną rolę.

Kto jest Właścicielem Produktu? Ale serio?

Rola Właściciela Produktu (Product Owner) w Scrumie nieprzypadkowo nazywa się tak, a nie inaczej. Pytanie nie powinno brzmieć: kto powinien pełnić rolę PO? lecz: kto jest prawdziwym PO, rzeczywistym właścicielem biznesowym produktu? Bo taka osoba na pewno w organizacji gdzieś jest, trzeba ją tylko poprawnie zidentyfikować, a następnie zadać sobie kolejne pytanie: co należy zrobić, żeby dana osoba mogła efektywnie uczestniczyć w Zespole Scrumowym?

Przeszkody, jakie najczęściej stoją na drodze, by rzeczywisty właściciel biznesowy mógł być PO w Zespole Scrumowym, to brak przygotowania i brak czasu.

Brak przygotowania

Menedżer produktu nigdy nie będzie gotowy do bycia PO, jeżeli nie zacznie działać w ten sposób. Udział w szkoleniu czy warsztatach ze Scruma może być dobrym początkiem, ale przede wszystkim liczy się nabywanie umiejętności w praktyce. Jest to także odpowiedzialność Scrum Mastera, żeby rzeczywistego PO poprawnie zidentyfikować, a następnie przygotować do pełnienia tej roli, wspierać go w pracy codziennej i nieustannie uczyć efektywnego wykorzystywania Scruma do zwinnego zarządzania rozwojem swojego produktu.

Brak czasu

„Ja nie mam czasu na pisanie historyjek, analizę wszystkich wymagań i określanie dokładnych kryteriów akceptacyjnych” — słyszę często od menedżerów produktów.

Może wcale nie muszą robić tego wszystkiego sami?

Przewodnik po Scrumie:

Właściciel Produktu jest jedyną osobą zarządzającą Rejestrem Produktu (Product Backlog). Pojęcie zarządzania Rejestrem Produktu mieści w sobie:

  • Jasne artykułowanie elementów Rejestru Produktu, […]

Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny.

I dalej:

Jak Scrum Master wspiera Właściciela Produktu?

  • W uczeniu Zespołu Deweloperskiego sposobów konstruowania jasnych i zwięzłych zapisów elementów Rejestru Produktu, […]

Tak więc sporą część pracy nad Backlogiem Produktu, takiej jak: formułowanie historyjek użytkownika, ich dekompozycja, określanie kryteriów akceptacyjnych itd., może przejąć na siebie z powodzeniem Zespół Deweloperski. Oczywiście w zgodzie z kierunkiem wytyczonym przez PO. Ważne, aby ten kierunek był skutecznie komunikowany przez Właściciela Produktu.

Na analityka w takim ujęciu należy spojrzeć nie jak na „proxy” między menedżerem produktu a deweloperami, a jak na jednego z deweloperów, pełnoprawnego członka Zespołu Deweloperskiego. Dołączając analityka do zespołu uzupełniamy kompetencje zespołu o analizę i skracamy ścieżkę komunikacyjną o jedno ogniwo ułatwiając kontakt zespołu z rzeczywistym Właścicielem Produktu.

Jak jest u Was? Czy w Waszym zespole macie do czynienia z prawdziwym PO czy z p.o. PO? Kto pełni tę rolę w Waszej organizacji?

Categories: Product Owner.

Moneyball i product ownership

Scena ze skautami z filmu Moneyball

Scena z filmu Moneyball

Seriously guys, I think we have to remember this is the man. He answers to no one except ownership and God. And he doesn’t have to answer to us. We make suggestions, he makes decisions.

Powyższy cytat pochodzi ze sceny filmu Moneyball, w której grany przez Brada Pitta menedżer klubu Oakland A’s Billy Beane, przedstawia swoją strategię dotyczącą kompletowania drużyny na nadchodzący sezon.

Podczas spotkania ze skautami, osobami zajmującymi się wyszukiwaniem talentów w celach transferowych, kontrowersyjna strategia spotyka się z brakiem zrozumienia i akceptacji, a skauci podważają każdy z wyborów Beane’a. Dopiero zacytowana powyżej wypowiedź jednego ze skautów kończy dyskusję.

W Scrumie to Właściciel Produktu podejmuje ostateczne decyzje dotyczące produktu, bo to on, nie kto inny, odpowiada za produkt. Można na niego wpływać, powinien słuchać sugestii, ale decyzje należą do niego.

Polecam cały film. Postać grana przez Brada Pitta to kwintesencja tego, co kryje się pod pojęciem product ownership.

Categories: Product Owner.

Codzienny Scrum a aktualizacja Backlogu Sprintu

Lata temu, kiedy firma dopiero rozpoczynała próby ze Scrumem, zespoły nie były ulokowane razem oraz nie używały żadnego webowego narzędzia do Scruma, Backlogi Sprintów były prowadzone w Excelu. Taki arkusz był aktualizowany raz dziennie podczas Codziennego Scruma. Zespół spotykał się w sali konferencyjnej, Scrum Master przynosił wydrukowany arkusz z Backlogiem Sprintu, uzupełniał go, po spotkaniu wracał do swojego pokoju, przepisywał dane na komputerze i wysyłał aktualny Backlog Sprintu do całego Zespołu Scrumowego. Razem z aktualnym Backlogiem Sprintu w mailu były zawarte prognozy dotyczące Sprintu, wykres spalania oraz zidentyfikowane podczas spotkania przeszkody.

Czasy się zmieniły…

Obecnie większość zespołów siedzi ulokowanych razem, Właściciele Produktów pracują w pobliżu, zespoły mają do dyspozycji analogowe tablice oraz narzędzie webowe do prowadzenia Backlogów Sprintów.

…nawyki pozostały

Mimo że zespoły mają obecnie możliwość aktualizacji Backlogu Sprintu na bieżąco, mało który to robi. Deweloperzy nadal wstrzymują się z aktualizacją backlogu do Codziennego Scruma, a spotkanie wygląda w ten sposób, że Scrum Master ma otwartą na laptopie aplikację z backlogiem, za jego plecami stoi reszta zespołu i każdy deweloper po kolei odpowiada na pytanie: „Ile godzin jeszcze zostało przy tym zadaniu?”. Zespół poświęca na to sporą część czasu spotkania, a samo spotkanie ma charakter statusowy, gdzie poszczególni członkowie zespołu raportują Scrum Masterowi. To nie powinno tak wyglądać.

Sumowanie godzin to nie jest podsumowanie

Wspólne podsumowanie pozostałej do wykonania pracy z Backlogu Sprintu jest ważne i powinno się odbywać co najmniej raz dziennie — podczas Codziennego Scruma. Pytania: „Co robiłem wczoraj?”, „Co będę robił dzisiaj?”, „Jakie mam przeszkody?” mają prowadzić do odpowiedzi na pytanie: „Co jako zespół zrobiliśmy od ostatniego spotkania i jaki mamy plan do następnego?”.

Żeby odpowiedzieć na te pytania, Zespół Deweloperski potrzebuje aktualnego Bakclogu Sprintu i wykresu spalania. Dlatego powinny one być aktualizowane na bieżąco, tak by podczas spotkania można było poddać zespołowej inspekcji postępy pracy i dostosować plan.

Jednak żeby móc się skupić na podsumowaniu, należy przestać skupiać się na sumowaniu godzin. Warto więc wprowadzić w zespole zasady, że:

  • każdy deweloper jest odpowiedzialny za aktualizację zadań, nad którymi pracuje;
  • backlog musi być zaktualizowany przed Codziennym Scrumem.

Backlog Sprintu warto aktualizować na bieżąco też po to, by zabezpieczyć się przed sytuacją, kiedy dwie osoby niezależnie rozpoczną pracę nad tym samym zadaniem.

Categories: Daily Scrum, Sprint Backlog.