Cel Produktu to odpowiedź na pytanie, dokąd aktualnie zmierza rozwój produktu. Wyjaśnia, czym kieruje się Product Owner przy definiowaniu elementów Backlogu Produktu i określaniu ich kolejności. Jest zatem opis stanu produktu, który Zespół Scrum zamierza uzyskać z korzyścią dla interesariuszy.
Artefaktem, który łączy się ściśle z Celem Produktu, jest Backlog Produktu, w którym ten Cel powinien być widoczny. Eliminuje to potrzebę zgadywania, do czego zmierza Product Owner, a jego samego zmusza do świadomego wyboru zarówno Celu (jednego spośród wielu, jakie się nasuwają), jak i tego, co powinno zostać zrobione, by go osiągnąć.
Cel Sprintu wyjaśnia, po co odbywa się bieżący Sprint. Jest więc odpowiedzią na pytanie, co interesariusze będą mieli z tego, że iteracja ta się odbędzie i Zespół Scrum włoży w nią siły i środki, jakimi dysponuje. Można też powiedzieć, że to opis stanu produktu, jaki Zespół Scrum zamierza uzyskać w trakcie iteracji, a który to stan będzie konkretnym krokiem w stronę osiągnięcia aktualnie obowiązującego Celu Produktu.
Artefaktem powiązanym z Celem Sprintu jest Backlog Sprintu, bo Cel stanowi jeden z trzech jego składników. Drugim jest prognoza tego, jak zmieni się produkt w wyniku prac Zespołu w bieżącej iteracji. Trzecim jest plan realizacji tej prognozy i zarazem odpowiedź na pytanie, w jaki sposób Zespół zamierza wyznaczony Cel Sprintu osiągnąć. Aby zapewnić przejrzystość zarówno planów, jak i postępów w ich realizacji, oraz by ułatwić ich dostosowywanie na bieżąco, gdy tylko ujawni się taka potrzeba, Cel Sprintu musi być widoczny w Backlogu Sprintu.
Obydwa Backlogi są elementami Scruma od samego początku. Od samego początku częścią definicji metody jest również Cel Sprintu, choć w 2013 jego waga została celowo podkreślona, bo sporo Zespołów Scrum nie uznawało za niezbędne kłopotać się ustalaniem Celów. Jego brak redukuje Sprint po prostu do interwału czasowego, w którego trakcie Zespół dąży do zrealizowania tego, co zaplanował. To najmarniejszy możliwy sposób użycia Scruma, bo Zespół skupia się, by wytworzyć jak najwięcej zmian w produkcie, a nie korzyści, jaką jego praca przynosi interesariuszom.
Cel Produktu pojawił się w Scrum Guide dopiero w wersji z listopada 2020. Jakim cudem twórcy metody przeoczyli wcześniej tak istotny jej element? Otóż nie przeoczyli, tylko wykazali się nie do końca uzasadnioną wiarą, że użytkownicy Scruma stosować go będą po coś, a nie wyłącznie do zarządzania realizacją listy rzeczy do zrobienia. W końcu postanowili, że trzeba napisać o Celu Produktu wprost, żeby wyeliminować nieporozumienia związane z Backlogiem Produktu i sposobem jego użycia.
I stało się to, co stać się musiało. Zarówno po wzmocnieniu znaczenia Celu Sprintu, jak i po dodaniu Celu Produktu do definicji Scruma, wiele Zespołów zaczęło mieć problemy z postępowaniem zgodnie z nią. Okazało się bowiem, że Cele ciężko zdefiniować, a jeśli już jakieś są, to marne, niezrozumiałe lub wręcz tworzone na odczepnego tylko po to, by formalnościom stało się zadość.
Z czego wynikają te problemy? Przyczyn jest wiele, ale w tym artykule skupię się na jednej z nich, a dokładniej na niewłaściwym pytaniu, jakie stawiają sobie osoby, które ustalają Cele Produktu (Product Ownerzy) i Cele Sprintu (Zespoły Scrum). O innych powodach napiszę wkrótce, bo zasługują na osobne omówienie.
Jakie pytanie taka odpowiedź
Wydawać by się mogło, że nikomu nie trzeba tłumaczyć, czym jest cel: to po prostu coś, co definiujemy (wyznaczamy, wytyczamy itd.), by następnie do tego dążyć. Skąd więc przestrzeń do nieporozumień? I o jakie pytanie chodzi?
Cel podejmowanych działań, niekoniecznie w Scrumie, ale i w każdym innym przypadku, można potraktować jako odpowiedź na pytanie o to, dlaczego (po co) działania te w ogóle są podejmowane. Przy czym pytanie to można sformułować na wiele sposobów, a każdy z nich przekłada się na nieco inny sposób definiowania celu.
Weźmy prosty przykład człowieka mieszkającego na prowincji, który wybiera się do stolicy. Zapytany po co jedzie do Warszawy, wyjaśni, że zamierza wziąć udział w rozmowie kwalifikacyjnej w jednej z firm. Gdy spytać go o efekt, jakiego spodziewa się po tym wyjeździe, odpowie, że jest nim dobrze płatna posada w dużej korporacji. A indagowany o to, jakiej zmiany w swoim życiu oczekuje w związku z wizytą w stolicy, opowie o możliwościach rozwoju osobistego i perspektywach, jakie otworzy przed nim zatrudnienie w wybranej firmie.
Podobnie rzecz ma się w przypadku Celu Produktu i Celu Sprintu. Mogą one być definiowane na trzech różnych poziomach i w zależności od wybranego poziomu wyjaśniać:
- co ma zostać wytworzone, czyli jaki ma być wynik realizowanych prac (ang. output);
- jaki efekt (ang. outcome) pozwoli uzyskać to, co zostanie wytworzone;
- co się zmieni (ang. impact) dzięki temu, że pojawi się efekt użycia lub działania tego, co zostanie wytworzone.
Wiele Zespołów z uporem maniaka definiuje Cele, które skupione są na wynikach (czyli określają output), ale nijak nie wyjaśniają, jaką przyniesie to korzyść komukolwiek. I od razu dodam, że nie chodzi o korzyść w rodzaju „będzie istnieć funkcjonalność XYZ” albo „będzie można użyć funkcji ABC”. Sam fakt istnienia jakiejś funkcjonalności czy funkcji nie oznacza od razu, że mają one wartość dla użytkowników lub ogólniej interesariuszy. Nie da się wykluczyć, że choć istnieją, działają w sposób nieprzystający od oczekiwań, albo wręcz są bezużyteczne ze względu na sposób, w jaki zostały zrealizowane.
Ponieważ Scrum to metoda rozwiązywania złożonych problemów w sposób przynoszący korzyści interesariuszom Zespołu Scrum, zdrowy rozsądek podpowiada, by unikać definiowania Celów (tak Produktu, jak i Sprintu) poprzez wskazanie, co ma powstać (jaki ma być output). Lepiej posłużyć się określeniem oczekiwanego efektu (czyli opisać pożądany oucome), a jeśli to możliwe, wskazać wpływ (czyli impact), jaki ma zostać wywarty na użytkowników, środowisko funkcjonowania produktu, rynek itd.
Przykłady Celów Produktu
Rozważmy produkt, jakim jest edytor tekstu. Powiedzmy, że istnieje już jakiś czas, zdobył pewną rzeszę użytkowników, ale wciąż wymaga intensywnego rozwoju. W szczególności coraz pilniejsze staje się umożliwienie tworzenia tekstów w różnych językach, bo na razie obsługiwany jest wyłącznie angielski. Gdy aktualnie obowiązujący Cel Produktu został osiągnięty, Product Owner postanawia, że nowy Cel będzie z tym właśnie związany. I zastanawia się, jak dobrze ubrać go w słowa.
Cel ten może przyjąć np. taką formę:
Umożliwienie tworzenia dokumentów w języku innym niż angielski.
Zespół skupi się wtedy na wytworzeniu mechanizmów niezbędnych do tego i uzna Cel za osiągnięty, gdy już będzie można edytować treści w języku polskim, niemieckim czy np. włoskim. Pojawi się bowiem wynik (czyli output) wskazany w definicji Celu.
I wszystko pięknie, tylko że ten wynik pojawi się również i wtedy, gdy ani jeden z użytkowników edytora tekstu nie będzie go używał do tworzenia dokumentów w języku innym niż angielski. Inaczej mówiąc, sam fakt istnienia możliwości nie oznacza od razu, że ktoś zechce z nich korzystać. A może nie zechcieć z wielu powodów, np. przez marną ergonomię rozwiązania, kiepski słownik, błędy implementacyjne lub choćby brak wiedzy o tym, że edytor pozwala pisać teksty w różnych językach.
Product Owner, by tego uniknąć, może zatem zdefiniować Cel np. w ten sposób:
Spowodowanie, by edytor był używany do tworzenia dokumentów również w językach innych niż angielski.
Aby go osiągnąć, konieczne stanie się uzyskanie konkretnego efektu (czyli musi pojawić się określony outcome) i nie wystarczy już tylko wytworzyć niezbędną do tego funkcjonalność. Trzeba zadbać, by użytkownicy zaczęli z niej korzystać: skutecznie poinformować ich o takiej możliwości, zapewnić dobrą użyteczność rozwiązań i ich jakość, a przede wszystkim sprawdzić, że efekt został osiągnięty.
Może okazać się, że pierwsze podejścia do wielojęzyczności będą nieudane, więc Cel Produktu będzie obowiązywał tak długo, aż iteracyjnie i inkrementalnie uda się dopasować produkt do oczekiwań użytkowników. I dobrze, bo to znaczy, że tylko wartościowe rozwiązanie pozwoli na uznanie Celu za osiągnięty.
Niemniej Product Owner uznał obsługiwanie wielu języków za istotne nie tylko dlatego, że na jej brak uskarżali się niektórzy użytkownicy. Gdyby tak było, dążyłby do wytworzenia rozwiązania minimalnego i zarazem wystarczającego. Jest jednak przekonany, że opłaca się zrobić dużo więcej.
Dlatego po namyśle ustanawia następujący Cel Produktu:
Spowodowanie, by edytor pozwalał tworzyć dokumenty w językach innych niż angielski i dzięki temu zaczął być używany w krajach posługujących się językiem hiszpańskim.
W ten sposób jasne staje się, że nie chodzi ani o konkretny wynik prac (nowe funkcjonalności), ani o efekt, jaki pozwolą one uzyskać (zadowolenie użytkowników z nowych możliwości edytora). Język hiszpański jest używany w wielu krajach, a statystyki, jakimi Product Owner dysponuje, pokazują mizerne zainteresowanie produktem w nich (co nie może dziwić, skoro edytor obsługiwał dobrze tylko teksty anglojęzyczne). Zamierza zatem wpłynąć na wybór edytora przez osoby używające na co dzień języka hiszpańskiego (czyli wywrzeć na nich impact) i w ten sposób otworzyć nowy rynek dla produktu.
Czy aby nie wyjdzie na to samo, co w poprzednim przypadku, skoro dobra obsługa wielojęzyczności obejmować będzie również z automatu język hiszpański? Z pozoru tak, bo różnica jest subtelna. Co nie znaczy, że nieistotna.
Nie wystarczy już bowiem implementacja obsługi wielu języków i upewnienie się, że użytkownicy faktycznie z niej korzystają. Trzeba będzie zrozumieć, czym różni się edytor budowany przez Zespół od rozwiązań popularnych wśród osób hiszpańskojęzycznych, aby móc zaproponować im lepszą alternatywę. A wszystkie zaawansowane funkcje językowe (np. tezaurus, tłumaczenie maszynowe itd.) powinny powstać przede wszystkim na potrzeby języka hiszpańskiego.
Przykłady Celów Sprintu
Product Owner ustalił zatem nowy Cel Produktu (określając pożądany impact) i pod tym kątem dostosował zawartość Backlogu Produktu i kolejność elementów w nim. Oznacza to, że starał się je ułożyć tak, by możliwie najszybciej uzyskać coś, czego da się użyć do potwierdzenia z użytkownikami, że rozwój mechanizmów obsługi wielu języków zmierza w dobrą stronę.
Rozpoczyna się Planowanie Sprintu i dyskusja nad tym, co ma być w jego trakcie zrealizowane. Oczywiście pojawia się potrzeba podjęcia decyzji odnośnie do tego, jak zdefiniować Cel (tym razem Cel Sprintu). Ten Cel musi być związany lub wręcz wynikać logicznie z Celu Produktu, który stanowi podpowiedź, na czym skupić powinny się kolejne Sprinty, a zatem czego dotyczyć powinny Cele tych Sprintów. Przy czym na razie planowany jest tylko Sprint bieżący (bo nigdy nie planuje się wielu iteracji z wyprzedzeniem!).
Jaki zatem mógłby być Cel Sprintu, który właśnie się rozpoczął? Elementy Backlogu Produktu opisują kolejne możliwości, w jakie wyposażyć należy produkt: wybór języka, w którym tworzony jest dokument, możliwość jego zmiany, sprawdzenie pisowni, dzielenie wyrazów, sprawdzenie interpunkcji, sprawdzenie poprawności gramatycznej, stylistyki itd. Jest tego sporo.
Zespół mógłby zgarnąć z góry listy tyle elementów, ile Developerzy uznają za możliwe do zrealizowania w czasie Sprintu, po czym zastanawiać się, jaki Cel pozwoli to osiągnąć. Równie dobrze (a nawet lepiej) byłoby, aby najpierw przedyskutował, jaki Cel Sprintu chciałby osiągnąć, a następnie poszukał możliwości, by to zrobić. Jest wtedy większa szansa, że Cel ten będzie skupiony na efektach, a nie samych wynikach prac.
Przykład Celu Sprintu wskazującego na pożądany output:
Wytworzyć mechanizm sprawdzania pisowni tekstu w języku hiszpańskim.
Brzmi marnie? Bo jest to marny Cel, który w istocie powiela informację o tym, co Zespół zamierza zrobić w Sprincie. Przecież wystarczy spojrzeć na prognozę (czyli listę elementów Backlogu Produktu podjętych do realizacji w Sprincie), żeby dowiedzieć się tego samego.
Inaczej mówiąc, ten Cel wyjaśnia, że Zespół chce zbudować mechanizm sprawdzania pisowni tekstu w języku hiszpańskim po to, by „Wytworzyć mechanizm sprawdzania pisowni tekstu w języku hiszpańskim”. Mam nadzieję, że czytelnie widać, jakie to miałkie. Równie dobrze można by ten Cel zastąpić prostym zapisem „Zrealizować prognozę”.
Cel Sprintu definiujący oczekiwany outcome mógłby mieć np. taką formę:
Na żądanie użytkownika edytor sprawdza ortografię oraz interpunkcję dokumentu pisanego w języku hiszpańskim i zaznacza znalezione błędy.
Już nie można ograniczyć się do wytworzenia niezbędnych mechanizmów, ale trzeba zapewnić, że opisany (prosty) scenariusz ich użycia faktycznie może zostać zrealizowany.
Tak zdefiniowany Cel Sprintu nie powiela informacji zawartej w prognozie, ale wyjaśnia, dlaczego znalazły się w niej te konkretne rzeczy do zrobienia. Jednocześnie stanowi odpowiedź na pytanie, jakiej korzyści z jego osiągnięcia mogą spodziewać się interesariusze (w tym przypadku użytkownicy).
Czy da się w ogóle zdefiniować Cel Sprintu, który wskazuje impact, jaki ma zostać wywarty na kogoś lub coś? To przecież wymaga faktycznego użycia produktu, co niekoniecznie nastąpi przed końcem Sprintu. Cóż, da się, choć nie w każdym przypadku – sporo zależy od tego, jaki ten Cel ostatecznie będzie.
Przykład takiego Celu Sprintu dla omawianego edytora i mechaniki sprawdzania pisowni w nim:
Edytor ogranicza liczbę błędów ortograficznych i interpunkcyjnych w dokumentach pisanych w języku hiszpańskim, bo zaznacza je i poprawia na bieżąco w trakcie pisania.
Zwracam uwagę na pewną przewrotność tego Celu: wymaga on zbudowania funkcjonalności, która pomaga użytkownikom, ale nie spowoduje, że będą się oni potykać o nią albo walczyć z narzędziem w trakcie edycji tekstu. Niemniej, jeśli uda się osiągnąć taki Cel, to jakość tekstów tworzonych za pomocą edytora (ich poprawność językowa) będzie zdecydowanie wyższa. Można powiedzieć, że jego wykorzystanie wpłynie pozytywnie na efekty pracy użytkowników.
Nic na siłę
Nie ma potrzeby na siłę zabiegać, by Cele Sprintu opisywały oczekiwany impact. Czasem nasunie się to w sposób naturalny, a jeśli nie, skupienie na efektach też będzie dobre. Grunt, by nie skupiać się na wynikach, bo output może powstać bez wykreowania żadnej wartości dla interesariuszy.
Natomiast w przypadku Celu Produktu zdecydowanie warto wysilić się na określenie wpływu, jaki produkt ma pozwolić uzyskać. I ewentualnie zadowolić się wskazaniem pożądanego efektu, jeśli impact jest trudny do zidentyfikowania. Natomiast pomysł, by jako Cel Produktu wskazać output (czyli jakąś dużą funkcjonalność produktu lub zmianę w nim) bez wyjaśnienia, jaką wartość ma ona przynieść, jest katastrofalny.
Zetknąłem się też ze zjawiskiem, że Zespoły i Product Ownerzy na siłę starają się szukać pięknych i nośnych haseł, by posłużyć się nimi przy definiowaniu Celów, bo głupio im przyznać, że faktycznym powodem prac nad produktem jest zlecenie ich przez kogoś. Inaczej mówiąc, robią to, co ma być zrobione, a dlaczego, tego nie wie nawet Product Owner.
Moim zdaniem nie warto tak robić. Nie malujmy zgniłej trawy na soczysto zielony kolor, bo wtedy wszyscy będą udawać, że jest dobrze i nigdy nic się nie zmieni. Jeśli Cele są marne albo ich brak, widoczność tego faktu ma szansę spowodować, że ktoś coś w końcu z tym zrobi. No, chyba że zagrażałoby to istnieniu Zespołu i sprowadziło na niego jakieś szykany za brak „urzędowego optymizmu” i psucie atmosfery – wtedy warto poszukać sobie innego miejsca pracy, w którym da się funkcjonować normalniej…
Inne przyczyny problemów z celami w Scrumie
Wspomniałem na początku artykułu, że wymóg definiowania Celów Produktu i Celów Sprintu sprawia niektórym Zespołom problemy z wielu powodów. Obiecuję, że napiszę i o nich.
