Jak duże powinny być elementy Backlogu w Scrum?

Gdy w Agile / Scrum planuje się Sprint lub iterację, ważne jest, aby zastanowić się, jak duże powinny być poszczególne Tasks.

Nie chcemy zbyt dużych Tasks

Trudno jest ocenić postęp zespołu, gdy pracuje się ze zbyt dużymi Tasks, ponieważ wtedy jest się zmuszonym do szacowania, ile procent tych Tasks zostało już ukończonych lub ile godzin jeszcze pozostało.

I to naprawdę nie jest proste. Znacznie łatwiej jest, gdy Tasks – jak w Scrum – mogą być jednoznacznie przypisane do binarnego stanu albo To Do, albo Done. Nie oznacza to jednak, że nasze Tasks powinny być zbyt małe.

Zbyt małe Tasks też mogą powodować problemy

Wtedy potrzebny jest większy wysiłek koordynacyjny, ponieważ jest więcej Tasks w iteracji.
W Iteration Planningu potrzeba więcej czasu na tworzenie Tasks.
Podczas iteracji potrzeba więcej czasu na zarządzanie i śledzenie Tasks.

Skoro zatem Tasks w iteracji nie powinny być ani za duże, ani za małe, jaka byłaby odpowiednia wielkość?

Istnieją dwie dobre wytyczne. Łącznie obie te wytyczne mogą pomóc Twojemu zespołowi w tworzeniu Tasks o dobrej wielkości dla Sprint Backlogu lub Iteration Backlogu.

Tasks powinny być wykonalne w ciągu jednego dnia

Pomyślcie tylko, jak wspaniale by było, gdyby wszyscy członkowie zespołu mogli powiedzieć codziennie podczas Daily Standup: „Wczoraj ukończyłem to zadanie i dzisiaj ukończę to nowe zadanie."

Jednak nie jest realistyczne twierdzenie, że każde zadanie powinno zajmować dokładnie jeden dzień. Dlatego po prostu przyjmijmy, że średni czas trwania Tasks powinien wynosić jeden dzień. Niektóre będą trwać nieco dłużej, inne krócej. Jednak przyjęcie jednego dnia jako celu dla średniej wielkości zadania to dobry cel.

Ale czy istnieją przynajmniej odpowiednie górne i dolne granice wielkości Tasks? Czy zespół może mieć 10-dniowe zadanie, jeśli zrównoważy się to kilkoma 5-minutowymi Tasks? Odpowiedź na to daje wytyczna nr 2.

Tasks powinny mieścić się w przedziale od 1 godziny do 2 dni czasu realizacji

Gdy dążysz do takiej średniej wielkości Tasks, warto ustalić pewne granice dla odpowiedniej wielkości. Proponowałbym przedział od jednej godziny do dwóch dni.

Staraj się unikać Tasks, które szacuje się na mniej niż godzinę. Członek zespołu będzie musiał poświęcić czas, żeby zastanowić się nad zadaniem. Może będzie musiał z kimś porozmawiać przed rozpoczęciem zadania. Być może też 10-minutowe zadanie trzeba będzie wykonać trzy razy, zanim w końcu wszystko będzie dobrze itp.

Jeśli Twój zespół naprawdę zidentyfikował coś, co zajmie 10 minut, po prostu powinni dać szacunek na 1 godzinę. Jeśli to zadanie zostanie ukończone w mniej niż godzinę, wyrówna to te Tasks, które zostaną skończone późno.

Proponuję górny limit 2 dni nie dlatego, że powinno być dużo 2-dniowych Tasks, ale dlatego, że od czasu do czasu mogą być Tasks, których nie da się ukończyć w ciągu jednego dnia.

Ważne jest, aby mieć tego świadomość i dopuszczać większe Tasks do Iteration lub Sprint Backlogu. Nie chcesz jednak Tasks w Backlogu tak dużych, że członkowie zespołu są zwolnieni z ciężkiej pracy dogłębnego przemyślenia problemu.

Wielkość elementów Backlogu

Ten jeden optymalny punkt między Tasks, które są za duże, a tymi, które są za małe, naprawdę istnieje. Jeśli będziesz się trzymać dwóch tu wymienionych wytycznych, pomożesz swojemu zespołowi znaleźć dokładnie ten punkt i odnieść sukces z Agile / Scrum.

Ten wpis pochodzi od Mike'a Cohna i został przez nas przetłumaczony na język polski.

Różnica między Story a Task

Dowiedz sie, jak odróznic Tasks od User Stories i jeszcze wiekszych elementow w Backlogu.
=> Roznica miedzy Stories a Tasks

Pisanie User Stories

Tutaj dowiesz się, jak najchętniej formuję User Story, aby była jak najłatwiejsza do zrozumienia.
=> Struktura dla User Stories

Nie identyfikować wszystkich zadań podczas Planningu

Aby uniknąć zbędnej pracy, Scrum Teamy nigdy nie powinny próbować określać wszystkich nadchodzących zadań.
=> Nie definiować zadań podczas Planningu