Scrum zmienia sposób, w jaki podchodzisz do zarządzania projektem. Zamiast próbować na początku szczegółowo opisać wszystko, co ma powstać, tworzysz Product Backlog, czyli uporządkowany rejestr potrzeb, funkcjonalności, usprawnień i innych elementów pracy nad produktem. Następnie zespół wybiera z niego te elementy, które mają największą wartość i które może zrealizować w najbliższym Sprincie.
Jednym z najważniejszych sposobów opisywania potrzeb w takim środowisku są User Stories, czyli historyjki użytkownika. Ich zadaniem nie jest zastąpienie rozmowy dokumentem. Wręcz przeciwnie – dobra historyjka ma tę rozmowę wywołać.
To ważna zmiana dla osób przyzwyczajonych do klasycznego zarządzania projektami. W tradycyjnym podejściu często zakłada się, że wymagania należy najpierw dokładnie zebrać, przeanalizować i udokumentować, a dopiero później przekazać je osobom odpowiedzialnym za realizację. Scrum zakłada znacznie większy udział klienta, użytkownika i zespołu w ciągłym doprecyzowywaniu tego, co powinno powstać.
Jeżeli chcesz dobrze zrozumieć agile i Scrum, zacznij właśnie od tej zależności:
potrzeba → User Story → Product Backlog → priorytet → Sprint → działający przyrost produktu → informacja zwrotna → zmiana lub doprecyzowanie Backlogu.
Nie traktuj więc Product Backlogu jak listy zadań, którą ktoś raz przygotował i której zespół ma się konsekwentnie trzymać do końca projektu. Product Backlog żyje. Zmieniają się priorytety, pojawiają się nowe informacje, część pomysłów traci znaczenie, a inne stają się pilniejsze.
To właśnie dlatego Scrum tak mocno opiera się na dialogu i krótkich cyklach pracy.
1. Product Backlog – centrum zarządzania produktem
Product Backlog, czyli rejestr produktu, możesz potraktować jako uporządkowaną listę wszystkiego, co może być potrzebne do rozwijania produktu. Znajdują się w nim między innymi funkcjonalności, usprawnienia, wymagania, poprawki błędów czy elementy techniczne.
Nie oznacza to jednak, że każdy element Backlogu ma od początku taki sam poziom szczegółowości.
Wręcz przeciwnie.
Elementy znajdujące się wysoko w rejestrze, czyli te, które mogą trafić do realizacji w najbliższym Sprincie, powinny być znacznie lepiej doprecyzowane niż elementy znajdujące się na dalszych pozycjach.
Możesz wyobrazić sobie Product Backlog jako magazyn, w którym towary ułożono według ich znaczenia. Na górze znajdują się rzeczy najbardziej wartościowe lub najbardziej potrzebne. Niżej znajdują się elementy, które mogą poczekać.
Taki sposób myślenia prowadzi do jednej z najważniejszych zasad:
Nie potrzebujesz szczegółowo opisywać dzisiaj tego, co być może będzie realizowane dopiero za kilka miesięcy.
Jeżeli wymaganie znajduje się daleko w kolejce, wiele rzeczy może się jeszcze zmienić. Klient może zmienić zdanie. Użytkownicy mogą zacząć korzystać z produktu w inny sposób, niż zakładano. Konkurencja może wprowadzić nowe rozwiązanie. Zespół może odkryć ograniczenie techniczne. Może też pojawić się zupełnie nowa potrzeba biznesowa.
Dlatego szczegółowe dokumentowanie każdego przyszłego wymagania często prowadzi do produkowania dokumentacji, która szybko traci aktualność.
W Scrumie priorytety mogą się zmieniać. Element, który miesiąc temu znajdował się na pozycji 3, dzisiaj może być na pozycji 15. Inny element może awansować z pozycji 20 na samą górę.
Możesz także usunąć element z Product Backlogu, jeżeli okaże się niepotrzebny.
To ważna różnica między podejściem zwinnym a myśleniem typowym dla części projektów kaskadowych.
W projekcie nie chodzi o to, żeby za wszelką cenę zrealizować wszystko, co kiedyś zapisano. Chodzi o to, żeby wytworzyć możliwie dużą wartość przy wykorzystaniu dostępnej wiedzy i aktualnych priorytetów.
Jak budować Product Backlog?
Praktycznie możesz przejść przez kilka kroków:
Warto przy tym pamiętać, że Product Backlog nie jest dokumentem, który powinien być „gotowy” przed rozpoczęciem pracy. Jego zawartość rozwija się wraz z produktem.
2. User Story, czyli jak opisać potrzebę użytkownika
User Story, czyli historyjka użytkownika, jest krótkim opisem funkcjonalności widzianej z perspektywy użytkownika.
Najczęściej stosowany szablon wygląda tak:
Jako [typ użytkownika] chcę [wykonać działanie], żeby [osiągnąć cel].
Przykład:
Jako klient sklepu internetowego chcę zapisać kilka adresów dostawy, żeby podczas kolejnych zakupów nie wpisywać ich ponownie.
Albo:
Jako kierownik chcę otrzymywać informację o przekroczeniu budżetu projektu, żeby móc odpowiednio wcześnie zareagować.
Albo w przypadku aplikacji szkoleniowej:
Jako uczestnik szkolenia chcę zobaczyć swoje wyniki po wykonaniu ćwiczenia, żeby wiedzieć, które obszary powinienem jeszcze przećwiczyć.
Zwróć uwagę, że User Story nie opisuje szczegółowo sposobu wykonania funkcji.
Nie mówi:
„Programista ma utworzyć tabelę w bazie danych X, następnie dodać pole Y i wykorzystać mechanizm Z”.
Opisuje potrzebę oraz wartość dla użytkownika.
To właśnie tutaj pojawia się jedna z najważniejszych idei Scrum i Agile: historyjka nie ma być kompletną specyfikacją techniczną.
Ma być punktem wyjścia do rozmowy.
To podejście wywodzi się z Extreme Programming (XP), a historyjki użytkownika zostały później bardzo szeroko przyjęte również w zespołach pracujących w Scrumie. W klasycznym ujęciu historyjka powinna być między innymi zrozumiała dla klienta, wartościowa dla użytkownika, możliwa do przetestowania i na tyle mała, aby zespół mógł ją zrealizować w krótkim cyklu pracy.
W materiale, na którym opiera się ten artykuł, pojawia się również konkretna wskazówka pochodząca z podejścia XP: historyjka powinna być na tyle mała, aby programiści mogli zrealizować około 6 historyjek w trakcie jednej iteracji. Nie traktuj tej liczby jako reguły Scrum. Scrum nie mówi, że każdy zespół ma realizować dokładnie 6 User Stories. To przykład pokazujący właściwą skalę historyjki: powinna być wystarczająco mała, żeby można było ją realnie zrealizować i zweryfikować w krótkim cyklu.
Czego nie robić?
Nie twórz User Story w taki sposób:
„Jako użytkownik chcę systemu”.
To zbyt ogólne.
Nie twórz też historyjki na kilkanaście stron, która zawiera kompletną specyfikację rozwiązania.
Problem pojawia się wtedy, gdy User Story staje się tylko inną nazwą dla klasycznego dokumentu wymagań.
Dobra historyjka powinna przede wszystkim odpowiadać na trzy pytania:
Dopiero rozmowa z zespołem pozwala ustalić szczegóły.
3. „Rozmawiaj zamiast pisać” – dlaczego sama dokumentacja nie wystarcza?
To jeden z najbardziej istotnych elementów podejścia Scrum.
Możesz stworzyć dokument mający 300 albo 400 stron, a mimo to nie mieć pewności, że zespół i klient rozumieją wymaganie w ten sam sposób.
Dlaczego?
Ponieważ dokument nie odpowiada na pytania, których jeszcze nie zadałeś.
W trakcie rozmowy możesz natomiast odkryć, że użytkownik miał na myśli coś zupełnie innego. Możesz dowiedzieć się, że funkcja ma być używana przez inną grupę osób. Możesz zauważyć, że istnieje prostszy sposób rozwiązania problemu. Możesz też odkryć ograniczenie, którego wcześniej nikt nie przewidział.
Dlatego User Story nie powinna być traktowana jako zamiennik rozmowy.
Historyjka przypomina o konieczności rozmowy.
To bardzo praktyczna zasada dla zespołu projektowego. Jeżeli ktoś mówi:
„Wszystko jest opisane w Backlogu, więc nie ma już o czym rozmawiać”,
to pojawia się ryzyko wypaczenia idei Agile.
W Scrumie klient, Product Owner i zespół powinni pozostawać w kontakcie. Product Owner nie powinien być wyłącznie osobą, która raz na miesiąc dostarcza zespołowi kolejną paczkę wymagań.
Szczególnie ważne jest to w przypadku produktów, których nie da się precyzyjnie zaplanować na początku.
Wyobraź sobie, że przez trzy miesiące analizujesz potrzeby użytkowników, przygotowujesz dokumentację, uzgadniasz wymagania i przekazujesz je zespołowi programistycznemu. Po kolejnych trzech miesiącach powstaje rozwiązanie. Dopiero wtedy użytkownik może je zobaczyć.
Może się okazać, że funkcja działa dokładnie tak, jak zapisano w dokumentacji, ale użytkownik wcale jej nie potrzebuje.
Formalnie projekt może być wykonany poprawnie.
Biznesowo może być jednak porażką.
Scrum ogranicza takie ryzyko dzięki krótkim cyklom i częstemu pokazywaniu efektów pracy.
Zamiast czekać kilka miesięcy na pierwszy kontakt z gotowym produktem, możesz pokazać działający przyrost już po jednym Sprincie. Jeżeli Sprint trwa 2 tygodnie, informacja zwrotna pojawia się znacznie wcześniej niż w klasycznym modelu, w którym efekt prac może być widoczny dopiero po wielu miesiącach.
To także zmienia rolę klienta.
Klient nie jest wyłącznie „dostawcą wymagań”. Powinien uczestniczyć w procesie rozumienia potrzeb, oceny efektów i ustalania priorytetów.
W praktyce oznacza to mniej myślenia:
„Powiedz dokładnie, czego chcesz, a zespół to zrobi”.
A więcej:
„Wspólnie sprawdzajmy, jaki problem warto teraz rozwiązać i czy rozwiązanie rzeczywiście daje wartość”.
Scrum: czym jest Product Backlog i jak tworzyć dobre User Stories? CZ. II
4. Jak połączyć User Stories z Product Backlogiem?
User Story sama w sobie nie jest jeszcze planem realizacji projektu.
To element Product Backlogu.
Możesz więc wyobrazić sobie następującą strukturę:
Product Goal → Product Backlog → User Stories → priorytety → Sprint → realizacja → działający przyrost → informacja zwrotna → aktualizacja Backlogu.
Przykład może dotyczyć platformy szkoleniowej.
Załóżmy, że celem produktu jest umożliwienie pracownikom samodzielnego ćwiczenia umiejętności komunikacyjnych.
W Product Backlogu mogą znaleźć się między innymi takie User Stories:
Nie wszystkie te elementy muszą mieć taki sam priorytet.
Product Owner może uznać, że najpierw trzeba umożliwić wykonanie ćwiczenia. Dopiero później warto rozwijać raporty dla trenera.
W efekcie kolejność może wyglądać następująco:
|
Priorytet |
User Story |
Poziom szczegółowości |
|
1 |
Wybór scenariusza ćwiczenia |
wysoki |
|
2 |
Informacja zwrotna po ćwiczeniu |
wysoki |
|
3 |
Historia wyników |
średni |
|
4 |
Raport dla trenera |
średni |
|
5 |
Zaawansowane raportowanie |
niski |
To nie jest kolejność ustalona raz na zawsze.
Jeżeli po pierwszym Sprincie okaże się, że użytkownicy najbardziej potrzebują historii wyników, możesz zmienić priorytety.
Jeżeli funkcja raportowania przestanie mieć znaczenie, możesz ją usunąć.
Jeżeli pojawi się nowa potrzeba, możesz dodać kolejny element.
Właśnie dlatego rejestr produktu jest żywy.
Nie jest kamienną tablicą wymagań.
Jest raczej mapą aktualnego rozumienia produktu.
Nie każdy element Backlogu musi być od razu szczegółowy
To jedna z praktycznych zasad, która bardzo ułatwia zarządzanie projektem.
Jeżeli masz pomysł dotyczący funkcji, która może być potrzebna za pół roku, nie musisz dzisiaj rozpisywać jej na kilkadziesiąt szczegółowych punktów.
Wystarczy informacja pozwalająca zachować ten pomysł w polu widzenia.
Kiedy funkcja zbliży się do realizacji, zespół może przeprowadzić rozmowę, doprecyzować wymaganie, ustalić kryteria akceptacji i podzielić większy element na mniejsze części.
Dzięki temu szczegółowość dokumentacji rośnie wraz z bliskością realizacji.
Możesz przyjąć prostą zasadę:
im bliżej realizacji, tym większa szczegółowość.
To ogranicza ilość pracy, która może zostać zmarnowana na analizowanie rzeczy, które ostatecznie nie trafią do produktu.
5. Jak pisać User Stories, które rzeczywiście pomagają zespołowi?
Dobra User Story powinna być przede wszystkim zrozumiała, wartościowa, możliwa do przetestowania i wystarczająco mała.
W praktyce warto sprawdzić kilka rzeczy.
1. Czy wiadomo, kto jest użytkownikiem?
„Jako użytkownik” często jest zbyt ogólne.
Lepsze może być:
„Jako kierownik zespołu…”
albo:
„Jako nowy pracownik…”
albo:
„Jako klient składający reklamację…”
Określenie roli pomaga zrozumieć kontekst.
2. Czy wiadomo, czego użytkownik chce?
„Chcę lepiej korzystać z systemu” jest bardzo ogólne.
„Chcę zapisać adres dostawy jednym kliknięciem” jest znacznie bardziej konkretne.
3. Czy wiadomo, po co użytkownik tego potrzebuje?
To właśnie tutaj znajduje się wartość.
Porównaj:
„Jako klient chcę mieć przycisk PDF”.
z:
„Jako klient chcę pobrać fakturę w formacie PDF, żeby móc przekazać ją do księgowości”.
Druga wersja daje zespołowi znacznie więcej informacji o rzeczywistym celu.
4. Czy możesz sprawdzić, czy historyjka została zrealizowana?
User Story powinna prowadzić do możliwego do zweryfikowania rezultatu.
W tym miejscu przydają się kryteria akceptacji.
Przykładowo:
User Story:
Jako klient chcę zapisać adres dostawy, żeby nie wpisywać go ponownie podczas kolejnych zakupów.
Kryteria akceptacji:
Teraz zespół ma znacznie bardziej konkretny punkt odniesienia.
Nie oznacza to jednak, że kryteria akceptacji powinny zamienić się w kilkunastostronicową specyfikację.
Ich rolą jest pomóc odpowiedzieć na pytanie:
„Po czym poznasz, że ta potrzeba została zrealizowana?”
5. Czy historyjka jest wystarczająco mała?
Jeżeli User Story brzmi:
„Jako klient chcę korzystać z całego systemu zakupowego, żeby robić zakupy online”.
to prawdopodobnie nie jest pojedynczą historyjką.
Można ją rozbić na mniejsze elementy:
Dzięki temu zespół może dostarczać wartość etapami.
Scrum nie oznacza „zero dokumentacji”
Warto zatrzymać się przy tym, ponieważ to jeden z częstych błędów w rozumieniu Agile.
Scrum nie mówi:
„Nie twórz dokumentacji”.
Chodzi raczej o to, żeby dokumentacja nie stała się celem samym w sobie.
Jeżeli dokument pomaga zespołowi zrozumieć rozwiązanie – korzystaj z niego.
Jeżeli diagram ułatwia komunikację – stwórz diagram.
Jeżeli dokument techniczny jest potrzebny ze względu na bezpieczeństwo, przepisy, utrzymanie systemu albo przekazanie wiedzy – przygotuj go.
Problem pojawia się wtedy, gdy zespół produkuje dokumentację tylko dlatego, że „tak zawsze robiono”.
W podejściu zwinnym większą wagę przykłada się do działającego produktu, współpracy, informacji zwrotnej i możliwości reagowania na zmianę.
User Story doskonale pokazuje tę filozofię.
Mały kartonik z krótkim opisem funkcjonalności może wyglądać niepozornie. Nie zawiera wszystkich informacji potrzebnych do jej wykonania. I właśnie o to chodzi.
Kartonik jest zaproszeniem do rozmowy.
Product Owner, użytkownik i zespół mogą dzięki niemu wspólnie ustalić:
To zmienia także odpowiedzialność osób zaangażowanych w projekt.
Programista nie powinien być tylko wykonawcą poleceń zapisanych w dokumencie. Projektant nie powinien dostawać wymagań bez możliwości zadania pytań. Product Owner nie powinien ograniczać swojej roli do przekazywania listy funkcji.
Scrum buduje odpowiedzialność zespołową za rozwiązanie problemu.
I właśnie dlatego rozmowa ma tak duże znaczenie.
Product Backlog i User Stories – co warto zapamiętać?
Jeżeli zarządzasz projektem, pracujesz w HR, jesteś liderem albo odpowiadasz za rozwój organizacji, warto zapamiętać kilka podstawowych zależności.
Product Backlog to uporządkowany rejestr elementów potrzebnych do rozwijania produktu. Nie jest zamkniętą listą wymagań. Zmienia się wraz z wiedzą, priorytetami i informacją zwrotną.
User Story opisuje potrzebę z perspektywy użytkownika. Najczęściej wykorzystuje konstrukcję:
Jako [typ użytkownika] chcę [działanie], żeby [cel/wartość].
Priorytet decyduje o tym, czym zespół powinien zająć się wcześniej. Elementy znajdujące się wysoko w Backlogu powinny być bardziej szczegółowe niż te, które znajdują się daleko w kolejce.
Rozmowa pozostaje kluczowym elementem pracy z wymaganiami. Historyjka nie powinna zastępować kontaktu z użytkownikiem, Product Ownerem i zespołem.
Kryteria akceptacji pomagają ustalić, po czym poznasz, że dana funkcjonalność spełnia oczekiwania.
Sprint pozwala przełożyć wybrane elementy Backlogu na konkretną pracę i działający przyrost produktu.
Najważniejsza zmiana dotyczy jednak sposobu myślenia o wymaganiach.
Nie musisz próbować przewidzieć wszystkiego.
Nie musisz szczegółowo opisywać każdej funkcji, która być może powstanie za rok.
Nie musisz traktować zmiany jako dowodu, że projekt został źle zaplanowany.
W Scrumie zmiana jest naturalnym elementem pracy nad produktem. Wraz z kolejnymi Sprintami pojawia się nowa wiedza. Użytkownicy przekazują informację zwrotną. Zespół odkrywa nowe możliwości. Zmieniają się potrzeby biznesowe.
Dlatego Product Backlog przypomina bardziej żywy rejestr decyzji i możliwości niż tradycyjną specyfikację projektu.
Jeżeli potraktujesz go w ten sposób, User Stories przestają być kolejnymi tabelkami do wypełnienia. Stają się narzędziem porządkowania rozmowy o tym, co warto zrobić, dla kogo, po co i jak sprawdzić, czy rzeczywiście przyniosło to wartość.
A właśnie na tym polega praktyczne wykorzystanie Scrum w zarządzaniu projektami.
