Artefakty Scrumowe #1 Product Backlog

16 sierpnia 2020 • 7 min to read

Ten pierwszy post w serii o Scrumowych artefaktach pozwoli Ci lepiej zrozumieć czym jest Product Backlog i jaką rolę pełni w Scrumie.

Spis treści

Wstęp

Jest wiele powodów dla których stworzyłam tego bloga. Jednym z nich jest pomaganie Ci w zrozumieniu najważniejszych informacji dotyczących Scruma. Oczywiście, możesz zrobić to także poprzez przeczytanie Przewodniku po Scrumie, ale nie znajdziesz tam przykładów z życia wziętych.

W ostatnich dwóch seriach postów opisałam wszystkie spotkania i role Scrumowe. Czas wyjaśnić Scrumowe artefakty. Wspomniałam o nich nieco w moich poprzednich artykułach, ale pozwól, że wyjaśnię więcej.

Zacznijmy od króla Scrumowych artefaktów, czyli Product Backlogu.

• Ten post jest zaktualizowany na podstawie Przewodnika po Scrumie 2020.

Co to jest Product Backlog?

Product Backlog jest naprawdę królem, ponieważ żadne z zadań Scrumowych nie mogłoby się wydarzyć bez niego. Wyobraź sobie, że pieczesz ciasto. Możesz to zrobić bez przepisu, ale musisz przynajmniej wiedzieć jakie składniki są potrzebne do tego ciasta. Product Backlog jest dla produktu tym, czym jest lista składników dla ciasta.

Bazując na Przewodniku po Scrumie:

Product Backlog to ewoluująca, uporządkowana lista tego, co jest konieczne do ulepszenia produktu. To jedyne źródło pracy podejmowanej przez Scrum Team.

Jedyne źródło wymagań

Dlaczego Product Backlog - uporządkowana lista ze wszystkimi “składnikami” jest taką ważną częścią Scruma?

Po pierwsze, jest to jedyne źródło prawdy, które mówi o tym, co jest wymagane w produkcie. Czy kiedykolwiek doświadczyłaś sytuacji, w której wiele ludzi pyta Cię o tę samą rzecz, ale wszyscy mają inne wymagania? Product Backlog jako lista pomaga w zebraniu tych wszystkich wymagań w jedno miejsce i uporządkowaniu ich. Minimalizuje ryzyko związane ze sprzecznymi wymaganiami lub z brakiem widoczności zmian.

Co więcej, dobrze zarządzany Product Backlog, wspiera przejrzystość/transparentność - jedną z 3 filarów empiryzmu, który jest podstawą Scruma.

Kto powinien zarządzać Product Backlogiem

Jest jedna rola w Scrumie odpowiadająca za zarządzanie Product Backlogiem - Product Owner. Ona lub on decyduje o tym co się znajduje w Product Backlogu oraz czy jest on dostępny dla wszystkich i uporządkowany. Product Owner upewnia się, że Product Backlog jest widoczny i jasny dla każdego członka Zespołu Scrumowego.

Stałe wymagania vs Product Backlog

W tradycyjnym zarządzaniu projektami, wszystkie wymagania są wymienione w dokumencie związanym z zakresem pracy na początku projektu i pozostają one niezmienne.

Zwinne (Agile) podejście promuje jednak inny sposób pracy z klientami i ich potrzebami. Wstępne wymagania są wypisane w Product Backlogu, ale lista ta zmienia się wraz ze zmianami związanymi z produktem i sytuacją na rynku. Oznacza to, że Product Backlog jest artefaktem, który jest stale aktualizowany i nigdy nie jest skończony.

Odpowiadanie na zmiany jest ważniejsze w Scrumie niż podążanie za ustalonym planem. Dlaczego? Ponieważ wszystko co się wiąże z produktem może ulec zmianie: użytkownicy, sytuacja rynkowa, strategia firmy. Nawet rzeczy takie jak światowa pandemia - COVID19 mogą zmienić całkowicie sposób użytkowania produktu. W związku z tym Product Backlog jest dynamiczny i istnieje tak długo jak istnieje produkt.

Product Backlog - co zawiera?

Ok, mamy magiczną listę zwaną Product Backlogiem, ale co się kryje w środku? Najlepsza odpowiedź to wszystko co wiąże się z produktem.

Bazując na Przewodniku po Scrumie - 2017:

Backlog Produktu jest listą wszystkich cech, funkcji, wymagań, ulepszeń i korekt, które reprezentują zmiany wprowadzane do produktu w jego przyszłych wydaniach.

W najnowszej wersji nie jest to określone. Jest to zapewne celowy zabieg, aby nie ograniczać sposobu interpretacji Product Backlogu.

Jest wiele sposobów przedstawiania Product Backlogu. Ja podzielę się z Tobą przykładami, których doświadczyłam. Na liście, której używał jeden z moich Zespołów Scrumowych, pojawiły się poniższe elementy:

• Epic - duża część funkcjonalności, która może być tworzona przez kilka Sprintów. Jest to ogólny zarys poszczególnych elementów produktu.

Zanim przejdę do opisywania dalszych elementów, chciałabym zaznaczyć, że często epiki (czasem razem z features, których tu nie wymieniłam) są używane do tworzenia tzw “Sprint Roadmap”, czyli Planu działania Sprintów, aby mieć mniej więcej zarys tworzenia produktu.

• User Story/Historyjka użytkownika - historyjki, to elementy Product Backlogu, które opisują konkretną potrzebę użytkownika. Zazwyczaj historyjka powinna być na tyle duża/mała, aby móc ją zrealizować w trakcie jednego Sprintu.

Powinna ona zawierać:

• Informację o tym kim jest użytkownik
• Opis co ten użytkownik chciałby zrobić, jaką ma potrzebę, którą chce zaspokoić
• Opis celu jego działania.

Przykładowo: Jako (użytkownik), chcę (co chce zrobić), aby móc (cel tego działania).

- Kryteria akceptacji - wszystko co jest wymagane od historyjki. Można to ubrać w format given, when, then - zakładając, że (kontekst), kiedy (akcja), wówczas (wynik tej akcji, co się wydarzy). Ten format jest tylko przykładem. Najważniejsze jest to, aby te kryteria wyjaśniały co jest wymagane w danej historyjce.

• Rozmiar - wyestymowany przez Deweloperów na Planowaniu Sprintu.

• Bug - opisuje on problem związany z jakąś funkcjonalnością w backlogu.
• Zadanie - Istnieje możliwość, że są techniczne zadania, które są wymagane do rozpoczęcia pracy nad produktem, a nie mieszczą się w historyjkach. Nie jest to norma, ale są zespoły, które używają tasków/zadań właśnie w ten sposób.
• Podzadanie - Historyjki mogą zawierać wiele mniejszych pod-zadań, które muszą być zrealizowane aby historyjka została ukończona. Jest to tak zwane “Jak”, które ustalają Deweloperzy. To oni ustalają wszystkie akcje, które są wymagane do ukończenia historyjki, aby móc uznać ją za “ukończoną”. Definicja “Ukończenia” jest używana przez nich do ustalenia jaki jest status danej historyjki.

Podane powyżej elementy, to tylko przykłady jak można opisać Product Backlog. Jest wiele innych sposobów. Na poniższym obrazku wyszczególniłam także inne elementy, które są używane przez niektóre zespoły. Pamiętaj, że to jak wygląda backlog, to decyzja Product Ownera i zespołu. Najważniejsze, aby backlog pomagał w dostarczaniu wartości.

Doskonalenie Product Backlogu (Refinement)

Kiedy jest potrzeba dokonania zmian w Product Backlogu, Właściciel Produktu oraz Developerzy spotykają się, aby zrobić tzw. refinement - doskonalenie. Co to oznacza? Aktualizują detale historyjek, estymaty, czy też ich kolejność. Analizują poszczególne historyjki, współpracują i dokonują wszelkich potrzebnych zmian.

Zgodnie z Przewodnikiem po Scrumie 2017:

Doskonalenie zazwyczaj zajmuje nie więcej niż 10% czasu Zespołu Deweloperskiego w Sprincie. Nie zmienia to faktu, że elementy Backlogu Produktu mogą być uaktualniane w każdej chwili przez Właściciela Produktu lub za jego zgodą.

10% nie jest wymienione w najnowszej wersji Scrum Guide. Znajdziemy tam tylko informację o tym, aby refinement traktować jako ciągłą/trwającą aktywność.

Kolejność w Product Backlogu

Elementy Produkt Backlogu, które są na jego szczycie powinny być najlepiej opisane. Im niżej jest położony element (historyjka, task itp), tym mniej detali jest wymaganych. Oznacza to, że Product Backlog nie musi być w pełni opisany od początku pierwszego Sprintu. Jedyna rzecz, która wtedy ma znaczenie, to elementy, które są najwyżej położone.

Zgodnie z Przewodnikiem po Scrumie z 2020:

Elementy Product Backlogu, które mogą zostać Ukończone przez Scrum Team w trakcie jednego Sprintu, zostają uznane za gotowe do wybrania podczas Sprint Planningu.

Przez “gotowe” - mają oni na myśli wystarczająco opisane, aby Deweloperzy mogli nad nimi pracować.

Podsumowanie

Najważniejsze informacje, które powinnaś zapamiętać z tego artykułu o Product Backlogu:

• Jest to uporządkowana lista, która jest jedynym źródłem wszystkiego co jest potrzebne w produkcie.
• Jest to żyjący artefakt, który jest aktualizowany kiedy występują zmiany oraz istnieje tak długo, jak istnieje produkt.
• Właściciel Produktu jest odpowiedzialny za zarządzanie Product Backlogiem: zawartości, kolejności, priorytetów itp.
• Product Backlog nie jest czymś stałym - jest nigdy nie skończony.
• Product Backlog może zawierać różnego rodzaju elementy np. Epik, User Story, Task, Bug itp.
• Product Backlog Refinement jest przeprowadzany w celu uzupełnienia detali w elementach Backlogu.
• Najwyżej położone elementy w Backlogu powinny mieć wystarczająco dużo detali, aby być Gotowe, co pozwoli Developerom pracować nad nimi.