Jak to jest z tym celem sprintu?

Cel sprintu? Potrzebny? Czy problematyczny? Jaki powinien być? Czy każda osoba w zespole powinna brać w nim udział?

To tylko kilka z pytań, które zaczynają się pojawiać po dłuższym czasie pracy z frameworkiem Scrum. Wg mnie nie da się ich uniknąć, wcześniej lub później po prostu muszą się one pojawić. Jeśli natomiast jesteś w gronie szczęśliwców i nie doświadczyłeś tych pięknych, metafizycznych rozważań, to patrz punkt pierwszy lub to po prostu znak, że wyjątek tylko potwierdza regułę 😀

Temat jest ciągle aktualny i przyznam, że pierwszy zarys tego artykułu zaczęłam pisać w marcu bieżącego roku i wielokrotnie do mnie to wracało, co ciekawe tylko delikatnie zmieniając kontekst.

Czas na Scrum Guid

By odpowiedzieć sobie dokładnie, wróćmy do źródła. Co mówi o tym artefakcie bezpośrednio Scrum Guid? W swoich rozważaniach opieram się na jego najnowszej aktualizacji z listopada 2020.

Cel sprintu (tzw. Sprint Goal) to kluczowy element, który nadaje kierunek pracy zespołu w trakcie trwania sprintu. Określany jest podczas planowania (Sprint Planningu) i służy jako strategiczne wytyczne dotyczące tego, co ma być osiągnięte w nadchodzącym timeboxie.

Tak więc:

1. Daje zespołowi jasny kierunek i cel, do którego wszyscy mogą dążyć.
2. Pomaga utrzymać skupienie na najważniejszych zadaniach – to dzięki nim będzie możliwe osiągnięcie większych celów produktu.
3. Jest drogowskazem, kryterium decyzyjnym w przypadku zmian w trakcie sprintu – modyfikacje powinny wspierać cel, a przynajmniej nie przeszkadzać.
4. Pozwala na samoorganizację zespołu i dostosowanie/skorygowanie w razie potrzeby planu. Patrzymy na cel i dostosowujemy się pod niego.

Cel sprintu związany jest z elementami/zadaniami wybranymi z backlogu do sprintu, ale jest bardziej strategiczny i związany z wartością, jaką zespół zobowiązuje się dostarczyć. Mimo, że najczęściej wytyczają go aspekty biznesowe i co za tym idzie bardzo konkretne funkcjonalności, to nie zawsze tak jest. Bardzo często kierunek wyznacza prototypowanie, nauka lub innym aspektem pracy wpływającym długoterminowo na zwiększenie wartości produktu, czy też po prostu wydajności zespołu.

Jak to wyglada w praktyce?

Odpowiem jak typowy informatyk – to zależy.

Czas na dygresję:
W Polsce Scrum jeszcze raczkuje i powstają różnego rodzaju tzw. scrumbut’y. Ale jak jeszcze sama firma typu softwarehouse jest wstanie udźwignąć framework coraz bardziej się dostosowując, to umowy pomiędzy klientami a dostawcą oprogramowania często nie są scrumowe, w tym sam klient nieraz nie jest Agile i dostarcza wymagania w różnej postaci.

Czy to jest element obligatoryjny? Czy typu nice to have?

Ze Scrum Guid wynika, że Cel sprintu jest artefaktem, który jest skrajnie zalecany i wskazany. Z życia mogę powiedzieć natomiast jedno – taki „tip and trick”:

Jeżeli podczas planowania zastanawiamy się ponad 15 min i nie jesteśmy wstanie dojść do konsensusu, to nie ma sensu z tym na siłę walczyć. Szkoda na to czasu.
Wtedy szczególną uwagę zwracam na kolejność zadań w backlogu sprintu i ich priorytety. Tą kolejność traktuję w takiej sytuacji jako zobowiązanie zespołu, a na dole zostawiamy rzeczy, dla których zawsze może być ryzyko, że wypadną, zostaną wymienione – coś może pójść nie tak.

Nie mniej jednak, taka sytuacja, gdy zaczyna się powtarzać, to powinna zostać poddana analizie.
Może to wskazywać na kilka kwestii:

1. Złożoność pracy: Projekt może być na tyle złożony, że różne zadania wymagają zróżnicowanych umiejętności i nie da się ich zebrać pod jednym wspólnym celem.
2. Rozmiar zespołu: Zespół może być na tyle duży, że pracuje nad różnymi aspektami produktu równocześnie, co utrudnia skupienie się na pojedynczym celu.
3. Etap projektu: Zespół może znajdować się w fazie, gdzie równolegle realizowane są różne ścieżki pracy (np. badania, prototypowanie, rozwój funkcjonalności).

W takich sytuacjach, Scrum Master i Product Owner powinni współpracować z zespołem, aby zrozumieć przyczyny i spróbować znaleźć sposób na lepsze zdefiniowanie celu sprintu. Czasami może to oznaczać potrzebę restrukturyzacji zadań lub nawet podziału zespołu na mniejsze, bardziej skupione grupy. Cel sprintu powinien nadal być używany jako narzędzie do zapewnienia jasności co do priorytetów i kierunku prac, nawet jeśli wymaga to większej elastyczności i kreatywności w zarządzaniu.

Jak to wyglądało u mnie w przeciągu tego roku?
Przede wszystkim problem, tak jak wspominałam w jednym z artykułów wynikał z wielkości zespołu. Tym był większy, tym obserwowałam coraz to większe problemy. Dodatkowo złożoność projektu, daje raz na jakiś czas o sobie znać 😀

Czy każda osoba w zespole powinna brać w nim udział?

W mojej opinii nie jest to dobre założenie. W idealnym świecie – tak. Natomiast z doświadczenia wiem, że przy większych zespołach i złożonych projektach mogłoby to powodować, że te cele stawałyby się bardzo obszerne.

Jak to wygląda u mnie?
Zawsze dążę do tego, by cel był bezpośrednio powiązany z wartością biznesową dla klienta – czasem może nie jest określone wprost, ale gdy popatrzymy na kontekst długofalowy, to jak najbardziej.