Na spotkaniu dot. Planowania Sprintu (ang. Sprint Planning Meeting) Zespół Scrum oraz Właściciel Produktu określają, które cechy i zadania będą poddane próbie wykonania w nadchodzącym sprincie.

Na Spotkaniu dot. Planowania Sprintu obecny jest Właściciel Produktu, Mistrz Scrum, cały Zespół Scrum oraz zainteresowani i odpowiedni przedstawiciele kierownictwa lub klienta. Podczas spotkania dot. planowania sprintu Właściciel Produktu opisuje zespołowi cechy o najwyższym priorytecie. W trakcie spotkania zespół zadaje dostatecznie dużo pytań tak, aby móc kontynuować po spotkaniu i określić, które zadania zostaną przesunięte z Rejestru Produktu do Rejestru Sprintu. Łącznie, Zespół Scrum oraz Właściciela Produktu określają cel sprintu, który jest krótkim opisem tego, co postara się osiągnąć sprint. Powodzenie sprintu zostanie następnie ocenione podczas Przeglądu Sprintu względem celu sprintu, a nie każdej specyficznej pozycji wybranej z Product Backloga. Po Spotkaniu dot. Planowania Sprintu, Zespół Scrum spotyka się oddzielnie, aby omówić to, co usłyszał i podejmuje decyzje odnośnie zaangażowania w zbliżającym się sprincie. W niektórych przypadkach mogą wystąpić negocjacje z Właścicielem Produktu, ale to zawsze zespół będzie decydował o tym, w jaki sposób zobowiąże się do wykonania.
Rejestr produktu może reprezentować wiele tygodni lub miesięcy pracy, czyli znacznie więcej zadań, niż można zrealizować w ciągu jednego, krótkiego sprintu. Zespół scrumowy przeprowadza planowanie sprintu, aby określić podzbiór najważniejszych elementów rejestru produktu do zrealizowania w nadchodzącym sprincie. Podczas planowania zespół scrumowy uzgadnia cel sprintu, a zespół deweloperski wskazuje konkretne elementy rejestru, które są zgodne z tym celem i które może z dużą dozą prawdopodobieństwa dostarczyć przed końcem sprintu. Aby uzyskać pewność pod względem tego, co może zostać dostarczone, zespół deweloperski planuje, jak zamierza zrealizować wskazane elementy rejestru produktu. Wybrane elementy rejestru oraz plan ich realizacji tworzą rejestr sprintu„[1].
Właściciel Produktu nie musi opisywać każdej pozycji śledzonej w Product Backlogu. W zależności od wielkości Backloga i szybkości zespołu, może wystarczyć opisanie jedynie pozycji o wysokim priorytecie, zostawiając omówienie pozycji o niższym priorytecie na kolejne Spotkanie dot. Planowania Sprintu. Na ogół, Zespół Scrum poda wytyczne, gdy lepiej zapozna się z listą Backloga, aniżeli gdyby miał polegać na tym, co ma być wykonane w następnym sprincie.
To co ważne podczas planowania sprintu to skupienie się tylko na wycinku rejestru produktu. „Tematy i epiki, które swoim rozmiarem przypominają słonia, też muszą zejść na dalszy plan. Całą naszą uwagę skupiamy teraz na historyjkach, które rozbijamy na kilkugodzinne zadania. W związku z tym nie przejmujemy się zbytnio punktami czy idealnymi dniami. W tym momencie są one zbyt abstrakcyjne, żebyśmy mogli ich używać. Świetnie sprawdzały się przy planowaniu wydania. Ale teraz przecież wiemy dużo więcej. Wtedy nie myśleliśmy o konkretnych zadaniach. Teraz dokładnie wiemy, co będziemy robić. Ludzie deklarują, ile czasu będą mogli poświęcić na pracę w sprincie. Tych informacji nie można lekceważyć” [4].
Wybór pozycji rejestru produktu wydaje się być prosty. „Jeżeli mamy określony cel sprintu, wybieramy elementy rejestru produktu zgodne z tym celem. Jeżeli cel sprintu nie został formalnie wskazany, z reguły bierzemy elementy znajdujące się na szczycie rejestru produktu. (..) Jeżeli zespół nie mógłby podjąć zobowiązania wobec kolejnego elementu na szczycie (na przykład ze względu na brak potrzebnych umiejętności w zespole), wzięty zostałby następny, który na pierwszy rzut oka wydaje się możliwy do zrealizowania w oparciu o bieżące ograniczenia„[1].
Tak jak napisałem wydaje się prosty. Niestety rzeczywistość jest dużo bardziej złożona. W nieidealnym świecie na etapie przygotowania rejestru sprintu Scrum Master musi pomóc nie tylko w wyborze odpowiednich pozycji z rejestru produktu, ale także często musi rozwiązać problemy związane z brakiem kompetencji (zapotrzebowanie na specjalistę). Co więcej na etapie przygotowania zadań może, po stronie zespołu deweloperskiego, pojawić się szereg wątpliwości i pytań. To niemal ostatni moment na doprecyzowanie oczekiwań Właściciela Produktu.

 

Cały cykl artykułów na temat metodyki Scrum jest pod adresem: https://www.michalwolski.pl/tag/metodyka-scrum/ . Zapraszam do lektury.  Kolejne wpisy z tego cyklu zostaną opublikowane w styczniu 2017 roku.

Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close