Tablica Scrum (ang. Scrum Board) to jeden z wielu elementów Scrum, który nie jest obowiązkowy, ale jest na tyle popularny, że nie można go zignorować.
The Scrum Board
Scrum Board to nic innego jak tablica prezentująca bieżący stan pracy w aktualnym sprincie. Może ona być prowadzona fizycznie (wykorzystując np. tablicę korkową) lub w sposób elektroniczny (np. przy w Jira lub przy użyciu innego, dostępnego na rynku narzędzia).
Zarówno zawartość, jak i postać tablicy ustalana jest przez Zespół Deweloperski. Istnieją oczywiście dobre praktyki, które sugerują pożądaną zawartość Scrum Board, ale ostatnie słowo jak zawsze należy do zespołu. A w tym przypadku możemy nawet rzecz, że pierwsze słowo również należy do niego. Jest on w końcu jedynym odbiorcą tego narzędzia!
„Poprzez codzienne monitorowanie pozostałej do wykonania pracy, Zespół Deweloperski zarządza postępami swojej pracy.” – Scrum Guide
Tablica ma przede wszystkim pomóc śledzić pracę w Sprincie. Na pewno powinny się na niej znaleźć wymagania realizowane w bieżącej iteracji. Mogą to być np. karteczki z wydrukowanymi User Story. Ale na Tablicy Scrum potrzebujemy także w jakiś sposób odwzorować stan ich realizacji.
Szczegółowość danych zwykle dobierana jest empirycznie. Jeżeli zespołowi czegoś brakuje – zaczyna to umieszczać na tablicy. Jeśli coś jest zbędne, Tablica Scrum jest oczyszczana.
Jak sprawdzić, gdzie jesteśmy?
Status realizacji wymagań nie bierze się z sufitu. Bardzo często w różnych zespołach napotkamy na trzy „klasyczne” kategorie umieszczane na Tablicy Scrum. Zwykle są to: To Do, In Progress, Done.
Jeśli zdecydowaliśmy, że do odwzorowania stanu naszego Sprintu będziemy używać Scrum Board, to umieścimy na nim wszystkie elementy, pozwalające na skuteczne śledzenie pracy. W takiej sytuacji te trzy kategorie to absolutne minimum. Bez tego funkcja śledzenia postępu prac przez naszą tablicę byłaby upośledzona.
Zespół ma możliwość dowolnego dostosowania Tablicy Scrum, np. poprzez dodawanie nowych, szalonych sekcji czy też umieszczane na niej poszczególnych zadań. Narzędzie to ma być użyteczne właśnie dla Zespołu Deweloperskiego i to zespół ma czerpać z niego potencjalne korzyści.
To nie Product Owner, ani nie Scrum Master ma „czuć” Scrum Board. Próba dogodzenia tym rolom może spowodować, że tablice nie będą używane, bo nikt się z nimi nie identyfikuje, nie rozumie ich albo wręcz uznaje za bezcelowe. Zespół powinien nie tylko wiedzieć, co da mu taka tablica, ale przede wszystkim – powinien jej chcieć.
Twoja Tablica Scrum
Nie da się ukryć, że chcemy rzeczy, które się nam przydają. Przestajemy robić rzeczy, które nie przynoszą nam żadnych korzyści. To absolutne podstawy motywacji, które i tutaj widać jak na dłoni.
Jeżeli zespół poświęca kilkadziesiąt minut dziennie na dostosowywanie Tablicy Scrum do tego, co już znajduje się np. w systemie Jira, to nic dziwnego, że powoduje ona negatywne uczucia. Nikt nie lubi marnować czasu. Zbyt skomplikowany Scrum Board bardzo szybko przestanie być aktualny, a stanie się bezużyteczny.
Z drugiej strony, jeżeli zespół tak ustalił statusy na tablicy, żeby pomagały mu one w spotkaniach Daily Scrum i jasno pokazywały, gdzie konieczne jest wprowadzenie limitów WIP (pracy w toku), to na pewno będą ochoczo ją aktualizować. Naprawdę trudno prowadzi się Daily Scrum bez możliwości odniesienia się do wymagań i zadań.
Zespoły też chętniej pracują z tym narzędziem, jeżeli Tablica Scrum jest naprawdę ich prywatną własnością. Jeśli mogą tam poprzypinać swoje zdjęcia, zniżki na pizzę, logo swojego zespołu, itd. to na pewno poczują się z nią bardziej związani. Tylko bez przesady z ozdobnikami, Scrum Board zawsze musi spełniać swoją podstawową funkcję!
Chodzi też o to, żeby czas poświęcany na utrzymywanie tablicy w stanie pełnej transparentności nie był zbyt duży w stosunku do odnoszonych korzyści. Im więcej dostajemy, tym więcej jesteśmy w stanie zainwestować.
Scrum Board w codziennej pracy
Zanim zaczniemy pracować z Tablicą Scrum, musimy ją przygotować. Zwykle dzieje się to po Planowaniu Sprintu, kiedy wiemy już co i jak będziemy realizować w bieżącej iteracji, a przynajmniej w jej pierwszych dniach. W sekcji Wymagania umieszczamy zakres najbliższego Sprintu, w sekcji To Do – zadania do wykonania.
Do decyzji zespołu należy stopień granularności zadań i częstotliwość ich aktualizacji. Rozbicie wymagań na małe zadania pomoże nam dokładniej śledzić prace, spowoduje jednak duży narzut czasowy na aktualizację Tablicy Scrum. Ujęcie poszczególnych zadań na wysokim poziomie ogólności da nam możliwość szybkiej aktualizacji, ale nie pozwoli na precyzyjne ustalenie aktualnego statusu Sprintu.
Codzienna praca ze Scrum Board polega na aktualizacji statusu poszczególnych zadań znajdujących się na tablicy. Dzięki temu Scrum Team ma okazję do weryfikacji aktualnego statusu prac i podjęcia działań mających na celu rozwiązanie ewentualnych problemów („wyzwań”) związanych z realizacją Celu Sprintu.
Przepięcie fizycznej karteczki na widocznej dla całego zespołu tablicy zmusza do refleksji. Czy na pewno dane zadanie jest skończone? Czy nie wprowadzę nikogo w błąd nadając jej np. status „do testów”?
Scrum Board kontra Kanban Board
Przyznam się Wam, że na początku swojej przygody ze Scrum myślałem, że pracuję na tablicy kanbanowej. Dopiero później, kiedy posiadłem wiedzę w zakresie Kanbana (o którym opowiem w osobnym artykule), dowiedziałem się czemu służy Kanban Board i jak powinien być wykorzystywany. Dziś wiem już, że od zawsze pracowałem na Scrum Board, czyli Tablicy Scrum.
Na pozór wydaje się, że tablice scrumowe i kanbanowe są takie same. Obie przecież zawierają listę elementów, wraz z wyszczególnieniem ich stanów. Co odróżnia oba typy tablic? Paradoksalnie różnić jest sporo, ale dziś przytoczę dwie, które najlepiej pasowały będą do podkreślenia zasad metodyki Scrum.
Pierwsza z różnic to limitowanie pracy w toku (Work In Progress). W Kanbanie każdy ze stanów ma przypisany współczynnik WIP. Oznacza to, że w jednym stanie (np. In Progress) nie może znajdować się więcej elementów niż wartość wskaźnika. W Scrum takie podejście jest opcjonalne i bardzo rzadko wykorzystywane. Wymaga to przede wszystkim większej szczegółowości statusów.
Drugą różnicą jest ograniczenie czasowe. Na Scrum Board ograniczeniem czasowym jest długość Sprintu. Wynika to bezpośrednio z założeń metodyki Scrum. Na Kanban Boardzie ograniczenie czasowe nie występuje, bo Kanban nie dzieje się iteracyjnie, ale ciągle. Zmienia to zupełnie częstotliwość i sposób czyszczenia tablic z zadań już zrealizowanych.
Czy musimy korzystać ze Scrum Board?
Istnieje wiele możliwości wizualizowania przebiegu pracy w sprincie. Jedną z nich, i chyba najbardziej popularną, jest Scrum Board. Czy jego używanie jest niezbędne? Oczywiście, że nie. Ponownie przypomnijmy sobie cytat ze Scrum Guide:
„Poprzez codzienne monitorowanie pozostałej do wykonania pracy, Zespół Deweloperski zarządza postępami swojej pracy.” – Scrum Guide
W Scrum nie ma mowy o konieczności wykorzystania Tablicy Scrum. Jasno jest powiedziane, że zespół powinien monitorować swoje postępy. Oznacza to, że to oni sami decydują z czego będą korzystać. Patrząc jednak na korzyści wynikające z używania tablic – warto pójść w tę stronę.
Tematykę wizualizacji postępu prac, w tym także Scrum Boardów, poruszamy w szczegółach na naszych warsztatach i szkoleniach Scrum.
