Przykładowa lista kontrolna dla
Scrum Masterów
Autor: Michael James (​mj4scrum@gmail.com​ )Tłumaczenie na język polski: Bogdan Brześciński (​Bogdan.Brzescinski@procognita.pl​)
Wersja: 20 października 2019http://scrummasterchecklist.org/

Moderator na pełny etat?
Przeciętny Scrum Master może pracować z dwoma lub trzema zespołami jednocześnie. Jeżeliodpowiada ci ograniczenie twoich obowiązków do organizowania spotkań, pilnowania ram
czasowych i reagowania na przeszkody zgłaszane przez ludzi, to możesz pełnić tą rolę na częśćetatu. Zespół prawdopodobnie będzie funkcjonował lepiej niż przed wprowadzeniem Scruma iraczej nie wydarzy się żadna katastrofa.
Jeżeli jednak marzy ci się zespół, który w zmieniającej się organizacji osiąga cele dotąd uważaneza niewykonalne, to rozważ zostanie​ świetnym Scrum Masterem.
Świetny Scrum Master pracuje z ​jednym Zespołem​ w danej chwili. Szczególnie na początku waszej
drogi zalecamy dedykowanego Scrum Mastera dla każdego Zespołu.
Jeśli nie odkryłeś jeszcze jak dużo jest do zrobienia, zwróć uwagę na:●●●●Product Ownera,Zespół,
praktyki inżynieryjne,całą organizację.

Chociaż nie ma jednego przepisu dla wszystkich firm to poniższa lista zawiera typowe obszary,których Scrum Masterzy często nie dostrzegają. Przechodząc przez listę oznacz każdy kwadrat za
pomocą √, Δ, ?, lub N/A, zgodnie z opisem zawartym na ostatniej stronie.

This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported LicenseCzęść I – Jak sobie radzi Product Owner?
Scrum Master zwiększa efektywność Product Ownera pomagając mu znaleźć sposoby na
utrzymanie Backlogu Produktu i Planu Wydań1. Pamiętaj, że to Product Owner jest odpowiedzialnyza priorytety Elementów Backlogu Produktu.

□ Czy B​ acklog Produktu​ jest ułożony zgodnie z ostatnią koncepcją Product Ownera?
□ Czy wymagania i potrzeby w​ szystkich interesariuszy​ są widoczne w Backlogu Produktu?
Pamiętaj: Backlog Produktu nigdy nie jest kompletny i ewoluuje wraz z rozwojemProduktu.

□ Czy Backlog Produktu jest o​ dpowiednich rozmiarów?​ Aby osiągnąć zarządzalną liczbę
elementów, te na górze Backlogu Produktu powinny być niewielkie i szczegółowe, zaś tena dole – duże i ogólne. Nadmierna analiza elementów o niższym priorytecie jestzbędna. Twoje wymagania będą się zmieniały na bieżąco w trakcie rozmów pomiędzyZespołem a interesariuszami i klientami.

□ Czy którekolwiek z wymagań (zwłaszcza te z góry Backlogu) może być lepiej
przedstawione zgodnie z koncepcja ​INVEST d​ la Historii Użytkownika2? Czy da się je
podzielić na mniejsze, niezależne części, które posiadają wartość dla użytkownika, dająsię oszacować i przetestować?

□ Czy wyjaśniłeś Product Ownerowi co to jest D​ ług Techniczny​ i jak go uniknąć? Ważnymelementem może być dołączenie automatycznych testów i refaktoryzacji3 do DefinicjiUkończenia4.

□ Czy Backlog Produktu jest miejscem pozwalającym wszystkim na szybki i ł​ atwy dostęp
do informacji​?

□ Czy wszyscy wiedzą​ jak korzystać z narzędzi​ do zarządzania Backlogiem Produktu,zwłaszcza jeżeli używasz elektronicznych wersji? Informacje gromadzone w narzędziach
elektronicznych nie są tak widoczne i łatwo dostępne jak w przypadku fizycznej tablicy.
Jeżeli Scrum Master nie wyciąga ich na światło dzienne mogą zostać zapomniane.

□ Czy przygotowujesz odpowiednie wydruki, aby udostępniać w​ ażne informacje​?
□ Czy d​ zielisz się​ informacjami tworząc duże i czytelne wykresy?
□ Czy pomagasz Product Ownerowi p​ rzyporządkować Elementy Backlogu Produktu doodpowiednich Wydań5?

□ Czy wszyscy znają​ faktyczny stan postępu prac​? Możesz spróbować pokazać Wykresy
Spalania6, po tym jak elementy zostaną uznane za „Ukończone” podczas Przeglądu

1(​orig​. Product Backlog and Release Plan)(orig. User Stories) ​http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
3(orig. Refactoring)4(orig. Definition of Done)
5(​orig​. Release)6(orig. Burndown chart) Mike Cohn, A​ gile Estimation and Planning​. (2005).
2This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported LicenseSprintu7. Wykresy pokazujące ilość faktycznie ukończonych oraz nowo dodanych
elementów pozwalają na wczesne wykrycie zmiany zakresu i harmonogramu prac.

□ Czy Product Owner ​zaktualizował Plan Wydania​ po ostatnim Przeglądzie Sprintu?
Product Ownerzy, którzy chcą dostarczyć produkt zgodny z oczekiwaniami poświęcajączas na ponowne planowanie Wydania po każdym Sprincie. Wraz z odkrywaniemnowych informacji często pojawia się potrzeba zmiany priorytetów i przesunięcia częścipracy do następnych wydań.

Część II – Jak sobie radzi Zespół?
Możesz dać dobry przykład współpracując z członkami Zespołu nad ich zadaniami, istnieje jednakryzyko, że za bardzo skupisz się na tematach technicznych. Dlatego weź też pod uwagę inne
obowiązki w stosunku do Zespołu.

□ Czy Zespół jest w stanie ​przepływu ? Poniżej kilka objawów tego stanu:
8

●
●
●
●
●
●Cele są jasno określone i osiągalne. Oczekiwania i reguły są znane.
Jest zachowana równowaga pomiędzy poziomem umiejętności a wymaganiami.
Zadania nie są zbyt łatwe ani za trudne.
Osoby pracują w skupieniu koncentrując się jednorazowo na wąskim obszarze.
Osoby otrzymują konkretną i natychmiastową informację zwrotną. Sukcesy i porażki
są widoczne w trakcie pracy, co pozwala odpowiednio na nie reagować.
Jest poczucie panowania nad sytuacją lub czynnością.
Działanie daje wewnętrzną satysfakcję, więc nie sprawia wysiłku.

□ Czy członkowie Zespołu l​ ubią się​ wzajemnie, spędzają wspólnie czas i świętująsukcesy?

□ Czy członkowie Zespołu wzajemnie pilnują utrzymywania ​wysokich standardów​? Czy
stawiają przed sobą wyzwania prowadzące do rozwijania umiejętności?

□ Czy są problemy lub możliwości, których omawiania Zespół u​ nika​, ponieważ powodujązbyt duży dyskomfort?9□ Czy próbowałeś różnych sposobów na p​ rzeprowadzenie Retrospektywy​?
□ Czy Zespół skupia się na ​Celu Sprintu ? Być może powinieneś pomóc Zespołowi
1011

przeglądnąć kryteria akceptacyjne dla elementów wybranych do obecnego Sprintu.

□ Czy​ Tablica Zadań Sprintu odzwierciedla to, co zespół faktycznie robi? Wystrzegaj się12ukrytych zadań i takich, które zajmują więcej niż jeden dzień pracy. Zidentyfikuj zadania
nie związane z zobowiązaniami Zespołu na obecny Sprint. Stanowią one przeszkodę dla
realizacji Celu Sprintu.
7(orig. Sprint Review)(orig. Flow) Mihaly Csikszentmihalyi, F​ low: The Psychology of Optimal Experience ​(1990), wyd. polskie: ​Przepływ​ (2008)
9Kerry Patterson, C​ rucial Conversations: Tools for Talking When Stakes are High ​(2002). Warto rozważyć wsparcie profesjonalnego
facylitatora, który sprawi, że rozmowy będą bardziej komfortowe.
10Derby/Larson ​Agile Retrospectives: Making Good Teams Great (​ 2006).
11(orig. Sprint Goal)
12(orig. Taskboard)
8This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported License□ Czy Zespół składa się z 3-9 osób. Czy posiada w​ szystkie umiejętności​ niezbędne dozbudowania Przyrostu Produktu przygotowanego do dostarczenia po każdym Sprincie13?

□ Czy Tablica Zadań Zespołu jest na bieżąco ​aktualizowana​?
□ Czy n​ arzędzia ​ułatwiające Zespołowi samozarządzanie (Tablica Zadań, Wykres SpalaniaSprintu, Lista Przeszkód14, itd.) są ​widoczne​, dostępne dla członków Zespołu i wygodnew użyciu?

□ Czy te artefakty są odpowiednio ​chronione p​ rzed osobami z zewnątrz? Nadmierna
kontrola przez osoby spoza Zespołu może utrudniać wewnętrzną przejrzystość isamozarządzanie.

□ Czy członkowie Zespołu s​ ami zgłaszają się​ do wybranych zadań?
□ Czy potrzeba spłaty Długu Technicznego została ujęta w D​ efinicji Ukończenia​? Czy kodstopniowo staje się bardziej czytelny i łatwiejszy w utrzymaniu?

□ Czy członkowie Zespołu zostawiają swoje tytuły i stanowiska za drzwiami,​ wspólnie
odpowiadając za całość pracy​ (testowanie, prowadzenie dokumentacji, itd.)?

Część III – Jak wyglądają praktyki inżynieryjne?

□ Czy​ środowisko deweloperskie​ daje każdemu możliwość łatwego, automatycznego
sprawdzenia czy zmiany nie uszkodziły wcześniej działającej funkcjonalności (testyregresji)? Zwykle jest to osiągane poprzez wykorzystanie środowisk xUnit (JUnit, NUnit,itp.).

□ Czy utrzymujecie odpowiednią równowagę pomiędzy a​ utomatycznymi ​testami
funkcjonalnymi (end-to-end) i testami jednostkowymi?

□ Czy cały Z​ espół zna język​, w którym pisane są testy funkcjonalne i jednostkowe?
Autorskie języki skryptowe i narzędzia do nagrywania testów obsługiwane przez
nielicznych członków zespołu utrudniają współpracę. Rozwiązaniem może być tworzenie
testów w tym samym języku, w którym jest tworzony produkt.

□ Czy Zespół odkrył użyteczną przestrzeń pomiędzy testami systemowymi a testami
jednostkowymi?15□ Czy system ​Ciągłej Integracji automatycznie powiadamia, gdy ktoś spowoduje błąd16

regresji? Czy ta pętla informacji zwrotnej może zostać jeszcze bardziej skrócona?
(„Codzienne kompilacje są dla mięczaków” – Kent Beck).

13(orig. Product Increment of Potentially Shippable Product)(orig. Impediments List)
15h​ ttp://blogs.collab.net/agile/2007/03/07/junit-is-not-just-for-unit-testing-anymore/
16(orig. Continuous Integration) h​ ttp://www.martinfowler.com/articles/continuousIntegration.html
14This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported License□ Czy w​ szystkie testy s​ ą częścią systemu Ciągłej Integracji?
□ Czy członkowie Zespołu doceniają wartość ciągłego projektowania i refaktoryzacji ,17jako alternatywy do projektowania wszystkiego z góry? R​ efaktoryzacja ​posiada ścisłą
definicję: zmienianie wewnętrznej struktury bez zmieniania zewnętrznych zachowań.
Refaktoryzacja powinna być procesem ciągłym zwłaszcza, gdy odkrywacie któryś zsygnałów alarmowych:●powielony kod,●rosnącą złożoność kodu,●
kiepsko nazwane elementy,●
nadmierne sprzężenia pomiędzy obiektami, itp.
Pełne pokrycie automatycznymi testami pozwala na bezpieczną refaktoryzację.
Natomiast zaniedbanie refaktoryzacji utrudnia zmianę produktu w przyszłości,zwłaszcza że ciężko znaleźć dobrych programistów chcących pracować nad złym
kodem.

□ Czy Definicja Ukończenia dla każdego Elementu Backlogu Produktu zawiera pokrycie
kodu automatycznymi testami i refaktoryzację? Korzystanie z T​ est Driven Development(TDD) zwiększa prawdopodobieństwo sukcesu.

□ Czy członkowie Zespołu p​ racują w parach ​przez większość czasu? Używanie tej metodymoże znacząco ułatwić utrzymanie kodu oraz zmniejszyć ilość błędów. Ponieważ stawia
to ludziom nowe wyzwania na początku jest niekomfortowe i może sprawiać wrażenie,że zabiera więcej czasu (tylko jeżeli mierzymy efektywność ilością linii kodu, a nieukończonymi funkcjami). Daj dobry przykład programując w parze z kolejnymi osobami zZespołu. Niektórzy z nich zaczną korzystać z tej techniki na stałe.

Część IV – Jak radzi sobie organizacja?

□ Czy Zespoły ​komunikują ​się między sobą w wystarczający sposób? „Scrum of Scrums”
jest tylko jednym ze sposobów na wymianę informacji i niekoniecznie najlepszym.

□ Czy Zespoły mogą n​ iezależnie ​od siebie dostarczać działające funkcje, w miarę potrzeby
modyfikując różne elementy architektury?18□ Czy Scrum Masterzy spotykają się i wspólnie pracują nad ​listą przeszkód w organizacji​?
□ Jeżeli jest taka potrzeba, czy przeszkody organizacyjne są umieszczone na ścianiegabinetu dyrektora działu/firmy? Czy ich koszt może być przedstawiony w gotówce,utraconym czasie lub jakości, albo utraconych szansach na pozyskanie klienta. Jednakucz się na błędach Ken’a Schwaber’a – „Martwy Scrum Master to bezużyteczny ScrumMaster”19.

17
18
19

Martin Fowler, R​ efactoring: Improving the Design of Existing Code (​ 1999)h​ ttp://FeatureTeamPrimer.org/Ken Schwaber, A​ gile Project Management with Scrum (​ 2004)
This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported License□ Czy organizacja oferuje ś​ cieżki kariery​ zgodne z celami Zespołu? Jeżeli promuje20

ścieżki związane z programowaniem i architekturą kosztem testów, automatyzacjiśrodowisk lub dokumentacji dla użytkownika, to odpowiedź brzmi „nie”.

□ Czy organizacja została uznana przez prasę branżową lub inne niezależne źródło jako
jedno z ​najlepszych miejsc pracy​ lub lidera w swojej branży?

□ Czy tworzycie u​ czącą się organizację​?
WnioskiJeżeli możesz odznaczyć wszystkie punkty na tej liście i jeszcze masz czas w ciągu dnia, tochciałbym Cię poznać.
Nie ma gotowej recepty na wzbudzenie ludzkiej kreatywności. Ten dokument zawiera listęobszarów, które mogą, lecz niekoniecznie muszą, pomóc w Twojej sytuacji.
Kiedy zdasz sobie sprawę co możesz zrobić, aby coś zmienić, możesz się zorientować, że boisz
się zmiany. Będzie to znak że jesteś na dobrej drodze.

20

Alfie Kohn, P​ unished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes (​ 1999)This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported License

INSTRUKCJAJeżeli otrzymałeś ten dokument jako element szkolenia a Twój pracodawca stosował Scruma lubpokrewne metodologie, proszę odnieś się do tego, co tam widziałeś. Zaznacz każdą kratkę jednymz poniższych symboli:

√Δ?
N/A

(idzie nam całkiem nieźle)(może być lepiej i wiem jak zacząć)(może być lepiej, ale nie wiem jak zacząć)(nie dotyczy/nie przyniesie żadnych korzyści)Jeżeli Twój obecny lub poprzedni pracodawca nie stosował Scruma lub metodologii pokrewnych,zaznacz każdą kratkę jednym z poniższych symboli:

√Δ?
N/A

(idzie nam całkiem nieźle/łatwe do osiągnięcia)(osiągnięcie będzie wyzwaniem, ale wiem jak zacząć)(osiągnięcie będzie wyzwaniem i nie wiem jak zacząć)(nie dotyczy/nie przyniesie żadnych korzyści)Gdy wypełnisz całą listę, ustal 2-6 przeszkód w Twojej organizacji i zapisz je na załączonychformularzach, niezależnie od tego, czy problemy znajdują się na tej liście kontrolnej. Wybieraj takie
przeszkody, które mają chociażby 1% szans na usunięcieThis work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported LicenseFormularz Przeszkód w Organizacji
Widoczny problem:

Prawdziwa przyczyna (użyj „5 x dlaczego?”):Wpływ na firmę:Efekt emocjonalny:

Jasne oczekiwanie:

Formularz Przeszkód w Organizacji
Widoczny problem:

Prawdziwa przyczyna (użyj „5 x dlaczego?”):Wpływ na firmę:Efekt emocjonalny:

Jasne oczekiwanie:This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported LicenseFormularz Przeszkód w Organizacji
Widoczny problem:

Prawdziwa przyczyna (użyj „5 x dlaczego?”):Wpływ na firmę:Efekt emocjonalny:

Jasne oczekiwanie:

Formularz Przeszkód w Organizacji
Widoczny problem:

Prawdziwa przyczyna (użyj „5 x dlaczego?”):Wpływ na firmę:Efekt emocjonalny:

Jasne oczekiwanie:This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported LicenseFormularz Przeszkód w Organizacji
Widoczny problem:

Prawdziwa przyczyna (użyj „5 x dlaczego?”):Wpływ na firmę:Efekt emocjonalny:

Jasne oczekiwanie:

Formularz Przeszkód w Organizacji
Widoczny problem:

Prawdziwa przyczyna (użyj „5 x dlaczego?”):Wpływ na firmę:Efekt emocjonalny:

Jasne oczekiwanie:This work is licensed under a​ C
​ reative Commons Attribution 3.0 Unported License