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.
Spis treści Podstawy Scrum
Scrum – Role:
Scrum – Produkty:
- Product Backlog – Rejestr produktu
- User Stories – Historyjki użytkownika
- Historyjki użytkownika a wymagania
- Dobre cechy historyjek użytkownika
- Dobre cechy rejestru produktu
- Sprint Backlog – Rejestr Sprintu
- Task Board – Tablica Zadań
- Sprint Burndown Chart – Wykres Spalania Sprintu
- Release Burndown Chart – Wykres Spalania Wydania
Scrum – Czynności:
- Daily Scrum – Codzienny Scrum
- Prioritizing the Backlog – Priorytezacja Rejestru Produktu
- Estimating the Product Backlog – Szacowanie Rejestru Produktu
- Sprint Planning Meeting – Planowanie Sprintu
- Release Planning – Planowanie Wydania
- Sprint Review – Przegląd Sprintu
- Sprint Retrospective – Retrospekcja Sprintu
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.
Reklama
„Wlasciciel Produktu określają, które cechy i zadania będą poddane próbie wykonania”
„obecny jest Właściciel Produktu, Mistrz Scrum”
… kiedy google translate wejdzie za mocno 😀
To nie google translate :-). To brak polskich odpowiedników słów oraz czasem złożoność myśli do przekazania połączona z moim roztargnieniem dają takie efekty:-)