Scrum Guide 2020 z komentarzami • Scrum Artifacts

Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

„Artefakty odzwierciedlają pracę albo wartość” – przyjrzyjmy się temu zdaniu.

Praca – czyli opis pracy, jednostki pracy – to coś, co znajduje się w Backlogach. W szczególności w Backlogu Produktu znajdują się elementy opisujące wartościową zmianę w produkcie (opisujące samą zmianę lub – lepiej – opisujące oczekiwane skutki dla interesariuszy, np. użytkowników), a w Backlogu Sprintu jednostki pracy opisujące plan działania Developerów i dające przejrzystość postępów pracy w Sprincie.

Z kolei Przyrost reprezentuje wartość. Wartość ta wynika z tego, że dzięki pracy Developerów Przyrost jest ukończony i nadaje się do użycia oraz z tego, że dzięki działalności Product Ownera (wyborze odpowiednich jednostek pracy do Backlogu Produktu) znalazły się w Przyroście zmiany powodujące, że produkt w tej nowej wersji jest bardziej wartościowy dla interesariuszy.

Sam fakt istnienia artefaktów zdefiniowanych w Scrumie nie determinuje ich przejrzystości. Odpowiedzialność za przejrzystość Backlogu Produktu spoczywa na Product Ownerze. Za przejrzystość Backlogu Sprintu i Przyrostu odpowiadają Developerzy.

A za przejrzystość których artefaktów odpowiada Scrum Master? Odpowiedź jest prosta: wszystkich, ponieważ odpowiada za uświadomienie Product Ownerowi i Developerom ich odpowiedzialności oraz nauczenie ich, jak się z niej wywiązać. Ma też obowiązek ujawnić brak przejrzystości któregoś z artefaktów – jeśli faktycznie tej przejrzystości brakuje. Oczywiście ujawniać nie po to, by wytykać Zespołowi braki, ale by doprowadzić do podniesienia jej poziomu.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

For the Product Backlog it is the Product Goal.
For the Sprint Backlog it is the Sprint Goal.
For the Increment it is the Definition of Done.

Słowo commitment jest w tym miejscu użyte nie w znaczeniu polskiego słowa zaangażowanie, ale zobowiązanie – to umowa, swoisty kontrakt, jaki zawiera sam ze sobą Zespół Scrum. Choć być może należałoby wręcz napisać, że to deklaracja intencji, czyli informacja o tym, jaki produkt, po co i w jaki sposób Zespół zamierza budować.

To, czy wymogi zawarte w Definicji Ukończenia zostały spełnione, czy osiągnięty został Cel Sprintu i Cel Produktu, musi być możliwe do ustalenia w sposób bezsporny – odpowiedź powinna być „tak” lub „nie”. Jako Zespół Scrum nie umawiamy się, że „spróbujemy z całych sił”, tylko umawiamy się, że zrobimy coś, o ile tylko jest to możliwe. Tu raz jeszcze warto wspomnieć, że chodzi nie o puste deklaracje, ale o faktyczne intencje członków Zespołu.

Czasami dopadną nas realia i okaże się, że jednak nie potrafimy osiągnąć tego, na co się umówiliśmy. Z tego faktu płyną dwa konkretne działania: urealnienie zobowiązań (ang. commitments), żeby były w ogóle w zasięgu naszych możliwość, a na podstawie różnic między nimi i zobowiązaniami, jakie chcielibyśmy spełniać, stworzenie przejrzystej listy rzeczy, których trzeba się nauczyć lub które trzeba zrobić najszybciej, jak tylko zdołamy. Konsekwencją będzie plan usprawniania, który pozwoli rozszerzyć zobowiązania do oczekiwanego przez Zespół poziomu.

Zwracamy też uwagę, że te zobowiązania odnoszą się do artefaktów przez cały czas ich istnienia – z tego wynika obowiązek utrzymywania ich w należytym stanie odpowiadającym zdefiniowanym zobowiązaniom. Nie może więc być tak, że Backlog Produktu tylko czasami odzwierciedla Cel Produktu, z którego zawartość i kolejność elementów tego Backlogu rzekomo wynika. Nie możemy też mówić o Przyroście, jeśli nie istnieje produkt nadający się do użycia i spełniający kryteria jakości zawarte w Definicji Ukończenia.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.