Kryteria akceptacji

Czym są kryteria akceptacji? Czym się różnią od Definicji Ukończenia? Przedstawiamy co to są kryteria akceptacji w oparciu o przykłady z życia. Podzielimy się też z Tobą praktycznymi wskazówkami, jak z nich prawidłowo korzystać.

W tym artykule znajdziesz następujące treści:

Ponieważ kryteria akceptacji to praktyka zwinna stosowana powszechnie, stąd nie musisz używać konkretnie Scruma, by z niej skorzystać. Warto pamiętać, że Przewodnik po Scrumie nie wymaga stosowania kryteriów akceptacji jako elementu obowiązkowego.

Czym są kryteria akceptacji?

Kryteria akceptacji to z góry ustalone warunki, które produkt, projekt albo ich fragmenty muszą spełnić, aby zostały zaakceptowane. Mówiąc prościej, są to kryteria, po których poznamy, że zrealizowaliśmy to, co chcieliśmy. W praktyce najczęściej mają postać kilku zapisanych punktów, które ustala zespół i jego otoczenie odnośnie do tego, co ma zostać zrobione. 

Kryteria akceptacji dobrze pokazać na przykładach. Załóżmy, że twój zespół dochodzi do momentu, w którym szykuje się do wytworzenia opcji logowania do aplikacji.

W tym przypadku można ustalić następujące kryteria akceptacji:

• Hasło musi się składać z minimum 8 znaków.
• Można się zalogować przy użyciu konta z innego serwisu.
• Widoczna jest formułka prawna o treści przygotowanej przez dział prawny (w realnej sytuacji tutaj powinna być konkretna treść tej formułki).
• Wpisanie błędnego loginu i hasła podświetla pole do wpisywania i wyświetla poniżej komunikat o błędzie: błędny login lub hasło.
• Można zaznaczyć checkbox: Zapamiętaj mnie na tym urządzeniu, który podtrzyma sesję użytkownika i nie będzie wymagał kolejnych logowań. 

Oczywiście kryteriów akceptacji w tym przykładzie mogłoby być więcej, natomiast podaliśmy tylko kilka przykładowych. Patrząc na powyższe kryteria widać, że jedne kryteria mówią o zachowaniu systemu, inne określają konkretne wymagania, jakie mają być spełnione. Jeszcze inne będą mówić o tym, jaki konkretny efekt ma uzyskać użytkownik.

Jak w praktyce dobrze korzystać z kryteriów akceptacji?

Poniżej znajdziesz 7 porad, które przygotowaliśmy na bazie naszego doświadczenia faktycznej pracy z zespołami zwinnymi.

1. Nie musisz mieć idealnych kryteriów akceptacji przed rozmową z zespołem

To często poruszana kwestia podczas naszych rozmów z Product Ownerami, którzy nie wiedzą, w jakim stopniu powinni być przygotowani do rozmowy z zespołem.

Nie musisz znać wszystkich detali i szczegółów, żeby rozpocząć rozmowę. To właśnie wspólna dyskusja jest okazją do tego, by wyłonić istotne elementy. Przed rozmową z zespołem przygotuj wstępne założenia, np. że można zalogować się do serwisu bez rejestracji. Dopiero w toku pracy warsztatowej ustalicie wraz z zespołem na przykładach, co konkretnie to oznacza i jakie macie możliwości techniczne.

Podobne dylematy mogą mieć też analitycy lub osoby wytypowane do przygotowania elementów Backlogu Produktu. Przestrzegamy przed przesadną ambicją w przygotowywaniu się do rozmowy. Nieświadomie można doprowadzić do sytuacji, w której kryteria akceptacji stają się zamkniętą, ostateczną formą specyfikacji dla zespołu. W wyniku nadgorliwości może bowiem zniknąć efekt współpracy, wspólnego odkrywania, rozumienia i dodawania stopniowo kolejnych detali konkretnej pracy do wykonania. 

2. Pisz kryteria akceptacji grupowo

Wspólna praca nad kryteriami akceptacji daje okazję do wykorzystania mądrości zespołu. Wróćmy do przykładu z logowaniem. Product Owner lub interesariusz biznesowy wymyśla logowanie, nie wiedząc, że warto zadbać o dwuskładnikowe uwierzytelnianie. Dzięki pracy grupowej osoba, która zna się na bezpieczeństwie, może wskazać minusy takiego rozwiązania. Może też zaproponować dodatkowe kryteria, które zwiększą bezpieczeństwo.

Rzecz jasna istnieją kryteria, które są oczywiste i nie trzeba nad nimi zespołowo dywagować. Każdy sam buduje sobie wyczucie, kiedy warto zaangażować zespół, aby zobaczyć inną perspektywę czy odkryć inny sposób rozwiązania konkretnego problemu.

3. Twórz kryteria, które są przydatne całemu zespołowi

Zwykle zespoły pracujące zwinnie są zespołami cross-funkcjonalnymi. Oznacza to, że posiadają wszystkie potrzebne kompetencje (np. programista, tester, analityk, specjalista od obsługi klienta), aby ograniczyć zależności zewnętrzne i od samego początku prac wytwórczych holistycznie patrzeć na produkt. Całościowe spojrzenie na produkt ma swoje odzwierciedlenie w procesie tworzenia kryteriów akceptacji.

Niestety często widzimy zespoły, które całkiem nieźle podchodzą do kryteriów akceptacji, ale widzą je wyłącznie z jednej perspektywy, np. programisty. Może to prowadzić do sytuacji gdy pomimo, iż kryteria akceptacji są rozległe, to nie dają testerom podstawy stworzenia scenariuszy testowych.

Zdecydowanie rekomendujemy podejście, w którym kryteria akceptacji tworzone są zespołowo. Może to oznaczać odrobinę kompromisów (np. nieco dłuższa dyskusja programisty z testerem, aby lepiej się zrozumieć). Widzimy jednak wielokrotnie, że wartość takiego podejścia jest nie do przecenienia.

 4. Zaproś interesariuszy do współtworzenia kryteriów

Interesariusz to osoba, która jest zainteresowana wynikiem realizowanego projektu bądź rozwijanego produktu. Może to być np. szef działu produktowego, przedstawiciel użytkownika, kierownik działu jakości, konkretny ekspert albo inny zespół z firmy.

Dlaczego warto ich zaprosić do procesu tworzenia kryteriów akceptacji? Wróćmy do przykładu strony logowania, która wymaga wyświetlenia odpowiednich formułek prawnych. Możliwe jest podejście do tego zagadnienia różnymi ścieżkami:

• Możemy wysłać prośbę do prawnika, aby przygotował treść formułki, a następnie po prostu umieścić ją na stronie.
• Jest możliwe przygotowanie pierwszej wersji samodzielnie przez zespół i przekazanie do zaakceptowania prawnikowi.
• Możemy zaprosić prawnika do rozmowy, opowiedzieć mu o naszym produkcie, o tym, czego potrzebujemy (np. jakie są wymiary tego, co tworzymy). To da wszystkim zainteresowanym lepsze zrozumienie tematu. A takie zrozumienie może doprowadzić do przygotowania właściwszych komunikatów lub wybrania lepszych miejsc na ich umieszczenie.

Może też się pojawić pokusa, żeby to Product Owner poszedł do interesariusza i zdobył wszystkie potrzebne informacje. Takie podejście tylko pozornie optymalizuje pracę, ponieważ po drodze generuje się możliwe przeinaczenia. Szum komunikacyjny w efekcie może być przyczyną błędów, które trzeba będzie i tak przegadać, więc i tak poświęcać na to czas.

Rekomendujemy, by zastanowić się kogo możesz zaprosić na sesję, podczas której Twój zespół kształtuje kryteria akceptacji, żeby pewne informacje usłyszeć z pierwszej ręki.

5. Nie wskazuj konkretnego sposobu implementacji

To często obserwowana przez nas pokusa, żeby kryteria akceptacji prowadziły zespół do bardzo konkretnego, jednoznacznego rozwiązania.

Wszelkie pomysły mocno zawężające pole do działania, mogą prowadzić do sytuacji w której albo nie otrzymamy optymalnego rozwiązania. W gorszym przypadku zamkniemy sobie drogę do dowiedzenia się, że pewne rzeczy można zrobić inaczej, lepiej, szybciej albo taniej.

Mocno przestrzegamy przed zbytnią konkretyzacją, która może wynikać z dobrych intencji ułatwienia komuś pracy. PO albo interesariusz może chcieć pokazać, że dokładnie wie, czego potrzebuje. Warto się zastanowić jak bardzo to, co jest formułowane, jest autentycznym kryterium akceptacji.

6. Obserwuj kryteria akceptacji pod kątem potencjalnych płaszczyzn cięcia

Im kryteriów akceptacji w wybranym zadaniu jest więcej, tym bardziej silny jest to sygnał, że najprawdopodobniej możesz to zadanie zdekomponować. Odpowiednie podzielenie elementów może doprowadzić do wartościowych wniosków produktowych. Być może nie trzeba wszystkich kryteriów realizować od razu, a być może pewne można w ogóle usunąć.

Warto poświęcić czas rozwijanie technik dzielenia elementów Backlogu Produktu, gdyż jest  to jeden z dużych atutów podejścia zwinnego. Odnosząc się do przykładu z logowaniem, niech w pierwszej fazie kryterium akceptacji będzie logowaniem za pomocą loginu i hasła, a dopiero w kolejnych fazach rozwoju produktu, będziemy dodawać kolejne opcje logowania za pośrednictwem popularnych w naszej grupie docelowej serwisów (np. Google, Facebook, Linkedin itp.).

7. Usprawniaj sposób wykorzystania kryteriów z zespołem

Wykorzystywanie kryteriów akceptacji to coś, czego zespół z czasem uczy się używać w lepszy dla siebie sposób.

Punktem startowym dla zespołu może być nauka od podstaw: czym są kryteria akceptacji i stopniowe uczenie się, jak z nich korzystać. Jeśli pracujesz w Scrumie, to Retrospektywa wydaje się być idealnym miejscem na głębszą refleksję na temat tego jak operujemy kryteriami akceptacji i czy jest coś, co możemy w tym obszarze zrobić lepiej.

Warto zwrócić uwagę, że pewne problemy zespołu (np. opóźnienia w realizacji pracy, niewłaściwe działanie produktu, duża ilość zgłaszanych błędów) mogą wynikać ze słabo przygotowanych kryteriów akceptacji. Nie jest to zależność widoczna na pierwszy rzut oka, dlatego warto w procesie refleksji i usprawniania się znaleźć czas, aby przyglądnąć się, jak to wygląda w Twoim zespole.

Dodatkowe materiały

• Definicja ukończenia
• Definition of Ready
• Porządny Backlog Produktu
• Porządny Refinement

Transkrypcja podcastu „Kryteria akceptacji”

Jacek: Prowadząc ostatnio szkolenie, usłyszałem pytanie – Czym tak naprawdę różnią się kryteria akceptacji od Definicji Ukończenia? To pytanie słyszę dosyć często, ponieważ wiele osób, albo stosuje zamiennie te podejścia, albo po prostu często je myli. Nagraliśmy z Kubą odcinek o Definicji Ukończenia. Jest to odcinek o numerze 88. Natomiast dzisiaj chcielibyśmy się skupić na opowiedzeniu Tobie, czym są kryteria akceptacji i jak z nich skorzystać. 

Kuba: Zanim wejdziemy w szczegóły, to chcemy jedną rzecz bardzo wyraźnie zaznaczyć, że kryteria akceptacji to praktyka, którą można zastosować w oderwaniu od Scruma. Czyli ten odcinek nie będzie stricte tylko i wyłącznie z perspektywy scrumowej. Chcemy tutaj również go kierować do osoby, która być może ze Scruma korzysta tylko w jakiejś części, albo w ogóle inspiruje się praktykami zwinnymi, no i chce zastosować praktyki, które są popularne. Pamiętajmy o tym, że Scrum sam w sobie, taki czysty, podręcznikowy, czy Scrum Guide’owy, nie wymaga stosowania kryteriów akceptacyjnych jako obowiązkowy element metody. 

Jacek: Co dzisiaj w odcinku? Na początek przedstawimy definicję kryteriów akceptacji, żebyśmy dobrze wiedzieli, o czym rozmawiamy. Następnie podzielimy się przykładem, jak mogą wyglądać kryteria akceptacji oraz podzielimy się wskazówkami co do tego, na co zwrócić uwagę podczas wykorzystywania kryteriów akceptacji w praktyce. 

Kuba: Więc zaczniemy od definicji. Kryteria akceptacji to z góry ustalone warunki, które produkt, albo projekt lub ich fragmenty musi spełnić, by zostać zaakceptowanym przez użytkownika, klienta albo interesariusza. 

Jacek: Mówiąc tak, absolutnie po ludzku, po czym poznamy, że zrealizowaliśmy to, co chcieliśmy. I w praktyce najczęściej forma, którą spotykamy, to po prostu zapisanie kilku punktów, kilku myślników, jakie ustala sobie zespół i jego otoczenie na temat tego, co ma być zrobione. 

Kuba: I zanim przejdziemy do przykładów, a później wskazówek, to jeszcze jedno szybkie ogłoszenie. Od kilku odcinków zapowiadamy przygotowanie produktu. Teraz możemy już ujawnić, że będzie to płatny webinar. Poruszymy w nim temat w sposób znacznie szerszy niż w podcaście, z wykorzystaniem wizualizacji, która w wersji audio nie jest możliwa. Mamy dla Ciebie prośbę. Pomóż nam wybrać tematykę webinaru, która byłaby dla Ciebie wartościowa. Zagłosuj na to, co Twoim zdaniem powinniśmy omówić w pierwszej kolejności na stronie porzadnyagile.pl/produkt. Tam znajduje się ankieta z propozycją kilku tematów, które przychodzi nam do głowy jako te, o których moglibyśmy nagrać webinar. 

Jacek: Wracając do kryteriów akceptacji. Będziemy operować na konkretnym przykładzie, żebyś mógł lub mogła lepiej zrozumieć, co tak naprawdę się kryje za tym pojęciem. I wyobraźmy sobie taką sytuację, że w trakcie rozwoju produktu czy realizowania projektu dochodzimy do sytuacji, w której chcemy porozmawiać o zbudowaniu logowania do aplikacji. I jakie Kuba moglibyśmy zaproponować do tak brzmiącego zadania, do tak brzmiącej pracy, kryteria akceptacji?

Kuba: Kilka kryteriów akceptacji, które zazwyczaj w tego typu sytuacjach zespoły sobie ustalają, mogłyby wyglądać następująco. Kryterium akceptacji numer jeden. Hasło musi składać się z minimum 8 znaków. Kryterium akceptacji numer dwa, mogę się zalogować przy użyciu konta z innego serwisu. Trzecie kryterium jest widoczna formułka prawna o treści dokładnie przygotowanej przez dział prawny. Realnym kryterium akceptacji pewnie nawet byłaby cała ta formułka, ale tutaj nie chcemy epatować jakimiś zdaniami, które mogą różne odruchy wywoływać. Kolejne kryterium wpisanie błędnego loginu i hasła podświetla pole do wpisywania i wyświetla poniżej komunikat błędu błędny login lub hasło. I piąty przykład na kryterium jeszcze inne od tych wszystkich poprzednich. Mogę zaznaczyć check box. Zapamiętaj mnie na tym urządzeniu, który podtrzyma sesję użytkownika i nie będzie wymagał ode mnie kolejnych logowań. 

Jacek: I zanim chwycisz za klawiaturę, żeby napisać do nas, że przecież do logowania brakuje jeszcze wielu innych kryteriów, to weź pod uwagę, że oczywiście jest to tylko przykład i dla podobnej funkcji w dowolnym systemie, takich kryteriów można ustalić bardzo dużo oraz mogą one brzmieć trochę inaczej niż te, które podaliśmy tutaj jako przykładowe.

Kuba: No i tak jak Jacek mówi, że może być wiele więcej kryteriów, to też oczywiście te kryteria mogą być różnego typu, takie dosyć różnorodne. Niektóre będą bardziej mówiły o tym, jak się zachowuje system, inne będą bardziej patrzyły na to, że są jakieś bardzo konkretne potrzeby, warunki. Nazwijmy je, może wymagania, rozumiane jako taki nieprzekraczalny wymóg, że system ma być jakiś, produkt ma się jakoś zachować. Ta funkcja ma z perspektywy użytkownika dać jakiś konkretny, oczekiwany efekt. Czasem on będzie bardzo, bardzo, bardzo precyzyjny. O wiele częściej w realiach takich życiowych to będzie coś, co lekko nas naprowadza na to, jakie są satysfakcjonujące czy oczekiwania, czy satysfakcjonujące wyniki tego produktu. Natomiast zasadniczą częścią, oprócz tego przykładu poprzedniego i definicji tego odcinka, ten odcinek chcielibyśmy poświęcić wskazówkom, czyli podpowiedziom, jak w praktyce dobrze korzystać z kryteriów akceptacji, co robić i ewentualnie na co uważać. 

Kuba: Jaka jest nasza pierwsza wskazówka, jeśli chodzi o kryteria akceptacji?

Jacek: Pierwsza wskazówka brzmi – Nie musisz mieć idealnych kryteriów akceptacji przed rozmową z zespołem. To jest generalnie pytanie, które bardzo często słyszę, najczęściej od Product Ownerów. Jak dobrze muszą być przygotowani do rozmowy z zespołem? To, co rekomendujemy, to to, że nie musisz znać wszystkich detali i wszystkich szczegółów, żeby rozpocząć rozmowę. Bo naturalnie taka rozmowa jest okazją do tego, żeby w trakcie tej rozmowy wyłonić rzeczy, które są istotne. Czyli przykładowo przed rozmową z zespołem mogę mieć wstępne założenie, że można się zalogować bez rejestracji w naszym serwisie i dopiero w toku pracy warsztatowej z zespołem ustalamy konkretnie na przykładach, co to może dokładnie oznaczać i jakie możliwości techniczne ujawnia przed nami zespół. 

Kuba: I tutaj logika za tym, żeby nie mieć idealnych kryteriów przed rozmową z zespołem. To jest zwłaszcza prawdziwe dla jakiejś funkcji typu Product Owner, Product Manager, ale czasami takie zagwozdki mają też np. analitycy, albo wytypowana jedna osoba, która miała przygotować trochę lepiej Backlog Produktu. Logika, żeby tego za dobrze nie zrobić, jest taka, żeby czasami te kryteria akceptacji nie stały się jakąś taką mikro wersją specyfikacji, z góry zdefiniowanego dokumentu. Tak kompletnego, tak rozpisanego i tak zupełnego, że wszystko, co mamy zrobić, to po prostu to A do Z, zaimplementować krok po kroku. I nawet nie tylko to jest najgorsze, ale ja się bardzo boję, że w ogóle znika wtedy ten efekt takiej współpracy czy współdziałania, wspólnego odkrywania, rozumienia, dokładania od siebie jakichś kreatywnych wkładów. No bo po prostu jest wszystko rozpisane, co do przecinka i co do kropki i co do kreski. I przynajmniej część osób, które obserwuję przy pracy, osób wchodzących w skład zespołów takich projektowych czy produktowych, potrafi dosyć łatwo odpłynąć, jeśli jest sesja bardziej czytania Backlogu Produktu, a nie sesja po prostu współpracy nad tym Backlogiem Produktu. No i to ustalenie kryteriów akceptacji jest tutaj akurat bardzo ważnym i bardzo zasadnym miejscem, żeby ta współpraca naprawdę następowała, a nie było tylko pasywne odsłuchanie, albo pasywne odczytanie tego, co ma być zrobione.

Kuba: Druga rada czy wskazówka to – Pisz kryteria akceptacji grupowo. Chwilę temu wspomniałem właśnie o tym przykładzie, że czasami te kryteria są autorstwa pojedynczej osoby wchodzącej w skład zespołu, albo pojedynczej osoby gdzieś w otoczeniu zespołu. Mamy tu na myśli taką sytuację, że wspólna praca daje też okazję do wykorzystania tych różnorodnych kompetencji, jakie w zespole na pewno są. Więc chociażby wrócimy do tego przykładu z logowaniem. Wyobraźmy sobie, że zespół czy np. interesariusz biznesowy, czy Product Owner wymyślała logowanie. Już zapamiętanie i niewylogowywanie. No i może w zespole jest np. ktoś, kto się dobrze zna na bezpieczeństwie i podpowiada, i uzasadnia, i opowiada całemu zespołowi, dlaczego nie jest to do końca mądry pomysł. W kontekście różnych produktów może być sugestia typu,  niech to kryterium będzie jednak zamienione, na pamiętamy sesję użytkownika przez jeden dzień, przez jeden tydzień, a nie w nieskończoność na przykład. Więc tutaj jest potencjał na to, że dzięki grupowemu przygotowaniu tych kryteriów akceptacji, wyciągniemy też unikalną perspektywę z różnych osób. I ta perspektywa będzie też wspólnie rozumiana. Z czego ona wynika? Jakie konkretne konsekwencje?

Jacek: I tak jak jestem absolutnie całym sobą za tym punktem i generalnie wywodzę się z takiej szkoły podchodzenia do kształtowania tego, co mamy do zrobienia, to dla równowagi dodam, że jeżeli pewne kryteria są absolutnie oczywiste i po prostu trzeba je zrobić, są jasne. To też jest okej, że coś takiego przynosimy do zespołu. Żeby uniknąć sytuacji, na zasadzie dobrze wiem, jakie są kryteria, ale to teraz Wy powiedzcie i je wypracujcie. No bo to trochę taka zabawa w kotka i myszkę. Ale to, co jest istotne, to dobre zrozumienie, kiedy jest ta sytuacja, że coś jest po prostu super oczywiste i to po prostu spiszę i przyniosę. A kiedy warto zaangażować zespół po to, żeby np. być może odkryć inny sposób zrealizowania, jakieś potrzeby, bądź rozwiązania konkretnego problemu. 

Jacek: Trzecia porada, którą mamy, brzmi – Twórz kryteria, które są przydatne całemu zespołowi. Zwykle zespoły, które pracują zwinnie, są tak skonstruowane, że posiadamy w zespole sporo profesji i sporo kompetencji, żeby ograniczyć zależności zewnętrzne i żeby takie holistyczne spojrzenie na produkt występowało od samego początku, kiedy startujemy, czy rozwój produktu, czy jakieś konkretny projekt. I warto by było, żebyśmy też od początku byli w stanie usłyszeć, nazwijmy to, takie potwierdzenie kompletności ze strony wszystkich członków zespołu. Czyli żeby każdy w tym swoim obszarze doświadczeń mógł dołożyć cegiełkę po to, żeby mieć pewność, że coś nam nie umknęło. I kiedy mówię o wszystkich członkach zespołu, to mam na myśli wszystkie te kompetencje, które w zespole się pojawiają. Czyli przykładowo: to może być tester, to może być programista, to może być analityk danych, to może być osoba odpowiedzialna za usability, za design, to może być copywriter. Tak więc każda osoba, która dokłada swoją cząstkę do tego, żeby powstał porządny produkt. 

Kuba: Ja to powiem, co Jacek powiedział trochę przez odwrotność. Niestety za często spotykam zespoły, które na przykład całkiem nieźle podchodzą do kryteriów akceptacji, ale widzą je tak, jakby tylko z jednej perspektywy. Najczęściej jest to perspektywa, przynajmniej w zespołach IT, jest to perspektywa programistów. No i na przykład testerzy potrafią narzekać, że kryteria akceptacji może i są rozległe, ale kompletnie nie dają im punktu wyjścia do przygotowania scenariuszy i w ogóle wykonania pracy testerskiej. Albo np. kryteria są na tyle zawężające, że ta sfera projektowania czy designu nie jest dobrze zaopiekowana, bo albo jest za mało miejsca, albo za mało punktów startu do przemyślenia pewnych działań. Więc w tej poradzie z Jackiem rekomendujemy podejście, które oznacza przydatność kryteriów całemu zespołowi, wszystkim jego członkom. Być może to oznacza też odrobina kompromisów, albo może inaczej nazwę – otwarcia się na to, że różni specjaliści wchodzący w skład zespołu będą mieli trochę różną potrzebę doprecyzowania pewnych rzeczy, pozostawienia ich otwartym, a na pewno przede wszystkim zrozumiałym. 

Kuba: Czwarta porada, jeśli chodzi o kryteria akceptacji, brzmi – Zaproś interesariuszy do współtworzenia kryteriów. Do tej pory wspomnieliśmy o tym, żeby robić to grupowo i robić to z perspektywą wszystkich członków zespołu. Ale coś, co też jest bardzo wartościowe, to zaproszenie osoby, które są interesariuszami dla danego zespołu projektowego czy produktowego. Kto to jest interesariusz? To jest oczywiście bardzo pojemny worek. To mogą być przedstawiciele użytkownika, przedstawiciele jacyś biznesowi, może klient, jeśli mówimy o jakimś partnerstwie B2B. Może jakiś konkretny ekspert albo inny zespół, u nas z firmy. Warto takie osoby, albo przedstawicieli takich zespołów zaprosić do tego, żebyśmy wspólnie działali na kryteriach. I mamy tu na myśli sporo rzeczy, ale na konkretnym przykładzie. Wyobraźmy sobie, czy wróćmy do tego kryterium akceptacji z przykładu logowania związanego z formułą prawną. Specjalnie jej nie przytoczyłem. I to jest realny problem w każdym zespole. Jak dokładnie takie komunikaty mają wybrzmiewać, bo one są z jakiegoś powodu super ważne. Jedno podejście byłoby takie, że wysyłamy informację do prawnika, powiedz nam, jak ma to wyglądać i gdzieś tam wiernie kopiujemy to, co przyszło i tak naprawdę uruchamiamy głuchy telefon. Możemy też pójść bardziej w model faktów dokonanych. Czyli przygotowaliśmy jakieś rozwiązanie, które nam się wydawało, że jest dobre i teraz próbujemy je wcisnąć do akceptacji prawnikowi, żeby to klepnął. W najgorszym razie, być może tuż przed wdrożeniem, albo już może po wdrożeniu. Natomiast w tym wariancie optymistycznym i pozytywnym, który chcemy w tym odcinku propagować, zaprośmy tego prawnika, opowiedzmy, tej osobie, która, która jest gdzieś tutaj fachowcem w swojej dziedzinie, to, co już wiemy o naszym produkcie, czego potrzebujemy, jakie są różne może wymiary. Porozmawiajmy wspólnie o różnych opcjach. Spróbujmy to też nazwać, spisać, ujednoznacznić. No i to powoduje, że prawdopodobnie – po pierwsze unikniemy jakichś takich brzydkich sytuacji, że nam się to wszystko przesuwa, opóźnia, ale też po prostu działamy mocno w duchu współdziałania, zrozumienia się wzajemnego, dobrego skomunikowania się. No a co ważne z perspektywy kryteriów akceptacji, ustalenia pewnych rzeczy na tyle wcześnie, na ile to możliwe i dobrego zrozumienia się wcześnie, a nie za późno lub bardzo późno.

Jacek: I tutaj często obserwuję taką pokusę, że po co ściągać tę osobę do zespołu. Przecież ja jako Product Owner czy Product Manager, czy ogólnie jakieś reprezentant biznesowy, po prostu pójdę, dowiem się, załatwię i po prostu przyniosę do zespołu. Moim zdaniem jest to taka pułapka generalnie. Pozornie optymalizujemy, natomiast po drodze jest cała masa szumu, przeinaczeń, które może spowodować, że albo coś dostarczymy, ale to nie będzie dokładnie oddawało istoty sprawy, albo to, co przeniesiemy, i to bardzo często obserwuję w zespołach, nadal generuje kolejne pytania, więc znowu musimy zabrać pytania, znowu się udać do tej osoby i wracamy. No i robi się nam po prostu głuchy telefon. Tak więc, o wiele lepiej, kiedy wiemy, że będziemy mieć jakąś taką sesję, podczas której kształtujemy kryteria akceptacji z wyprzedzeniem, zastanowić się, kto może nam pomóc. No i też z wyprzedzeniem zaprosić tę osobę, dać jej znać, kiedy ma dołączyć. No, żeby też nie było zaskoczenia, że ktoś nie może, no bo ma inne obowiązki. Na szczęście można to zaplanować. 

Jacek: Kolejna porada brzmi. Nie wskazuje konkretnego sposobu implementacji. Bardzo często obserwuję taką pokusę, żeby kryteria akceptacji prowadziły zespół już do konkretnego rozwiązania. I przykładowo, trzymając się tego przykładu, który przytoczyliśmy, mogłoby się pojawić bardzo konkretne wskazanie, gdzie dokładnie, jeśli chodzi o interfejs użytkownika, powinna się pojawić ta formułka prawna, o której przed chwilą rozmawialiśmy, w sytuacji, gdzie nie ma to tak naprawdę znaczenia. To gdzie ona zostanie umiejscowiona, tak naprawdę powinien wypracować zespół. Zakładam, że w zespole mamy osoby, które mają odpowiednie kompetencje do tego. Być może w ogóle dla produktu, który tworzymy, jest też przygotowany jakiś zestaw takich ram, norm, jak pewne rzeczy mają w produkcie wyglądać. Więc tak naprawdę zespół może do tego sięgnąć, zastanowić się, bądź po prostu wypracować to od zera. Wszelkie takie pomysły, żeby coś od razu bardzo mocno zawęzić, mogą prowadzić do takiej sytuacji, że albo nie otrzymamy optymalnego rozwiązania, albo w ogóle zamkniemy drogę do tego, żeby się dowiedzieć, że pewne rzeczy można zrobić inaczej, lepiej, szybciej albo taniej. 

Kuba: Tutaj pułapek może być cała masa. Jacek już niektóre wymieniłeś, ale ja bym poszedł jeszcze dalej, że też zbyt ścisłe sugerowanie implementacji może być bardzo frustrujące. To jest często perspektywa osób, które na przykład mają tę cząstkę pracy bardzo kreatywną i na przykład Backlogu, czy Product Owner przyniósł kryterium akceptacji, które brzmi jak po prostu sterowanie kogoś piksel po piksel. Na zasadzie w tej odległości, tu wyrównane, do tego. Tak naprawdę to jest robota zespołu wytwórczego. Na przykład osób od front-endu czy osób od designu. Ale na wielu innych poziomach też jest taka pułapka. Pułapka, która może kojarzyć się z byciem bardzo konkretnym, byciem bardzo jednoznacznym. Być może też takie wrażenie decyzyjności, że ja doskonale wiem, czego chcę. Natomiast moja przestroga w tym samym dokładnie miejscu, zwłaszcza dla tej funkcji produktowej, Product Ownera, Product Managera, czy osoby reprezentującej w tym miejscu biznes, zastanówmy się, na ile to, co formułujemy, jest autentycznie kryterium akceptacji, a na ile to jest niestety, ale takie jakieś uproszczenie, czy powiedzenie pewnych wymagań poprzez przykład. No i tak naprawdę to, co nas będzie satysfakcjonowało, jest o wiele bardziej np. otwarte, szerokie, albo ma więcej opcji niż ten dokładnie zapis, który został w tym miejscu zaproponowany. Innymi słowy, w toku dyskusji, w toku pracy nad kryteriami akceptacji, jedną z rzeczy, którą warto sobie wziąć do serca, zadać samemu sobie, czy w ramach całego zespołu zadać sobie pytanie: Na ile to, jak konkretnie to kryterium jest opisane nam pomaga? Na przykład w przygotowaniu rozwiązania, czy wymyśleniu, co tam dokładnie jest do zrobienia. A na ile nam niestety, ale od razu sugeruje konkretną, jedną, jedyną słuszną drogę. I co gorsza, to słuszna droga może jednak się okazać, po pierwsze nie za dobra. Po drugie wcale nie jest tania. Po trzecie wcale nie jest przydatna. Na przykład czy użyteczna odbiorcy końcowemu. Więc tutaj jest sporo pułapek w czymś, co mogłoby się wydawać bardzo niewinne i np. wiele osób ceniłoby to za to, że jest takie jednoznaczne, ułatwiające, prowadzące szybko do przodu z pracami. 

Kuba: Przedostatnia wskazówka, którą mamy dla Ciebie, to obserwuj kryteria akceptacji pod kątem potencjalnych płaszczyzn cięcia. Jak Jacek mówił o tym łapaniu za klawiaturę, to jesteśmy gotowi na to, że być może ktoś nie dosłucha odcinka do końca i np. nam powie, że te pięć, które już wymieniliśmy, to nie jest w ogóle dobre ujęcie, bo przecież to się daje pociąć. No i faktycznie tak jest, że chociażby ten przykład z możliwością logowania się z różnych serwisów, czy np. poprzez użycie konta z Facebooka, z Googla, Apple ID, czy jakichś innych jeszcze gotowych już sposobów logowania się, które można zaimplementować w jakiejś aplikacji, czy w serwisie, faktycznie jest kandydatem na przykład kryterium akceptacji, które tak naprawdę mogłoby uruchomić rozmowę o tym, że to da się pociąć, to się da pociąć nawet na parę sposobów. Co mamy na myśli? No na przykład być może w ogóle w pierwszej wersji jednak zrezygnujmy z tego kryterium akceptacyjnego, czyli zróbmy logowanie tylko i wyłącznie naszym loginem i hasłem, a logowanie się innymi serwisami stanowi zupełnie osobny element produktu, realizowany oddzielnie. I nawet samo to logowanie się też daje się podzielić. Czyli na początek wybierzmy logowanie się serwisem, które jest najbardziej popularne w naszej grupie docelowej. Cokolwiek to jest, zakładamy, że mamy takie dane. Czy akurat u nas ludzie się logują Tiktokiem, Instagramem czy Twitterem, czy może LinkedInem? A na przykład pozostałe 2/3 mniej popularne, ale nadal popularne to mogłoby być coś, co jest w Backlogu jakiegoś produktu trochę niżej w priorytetach. I zrealizujemy te priorytety w różnej kolejności, a część może nigdy. 

Jacek: Generalnie wskazówka, którą myślę warto tutaj dodać do tego, jest taka, że generalnie im bardziej nam puchną kryteria akceptacji, im tych kryteriów akceptacji jest więcej, tym bardziej jest to silny sygnał, że być może jesteśmy w stanie, albo coś w ogóle wyjąć kompletnie, albo dostarczyć na początku w trochę prostszej wersji. I warto poświęcić czas na poszukiwanie tych płaszczyzn cięcia, gdyż myślę, że to jest jeden z takich dużych atutów podejścia zwinnego, że niby mówimy cały czas o logowaniu i na koniec dnia to logowanie będzie zrealizowane. Natomiast kręcenie tymi suwakami, tymi pokrętłami może pozwolić nam na trochę większą swobodę, jeśli chodzi o to, jak konkretnie ujęte logowanie dostarczymy np. na koniec Sprintu.

Kuba: Ja jeszcze dołożę taką myśl, że tutaj akurat użyliśmy przykładu takiego funkcjonalnego, czyli jest możliwość logowania się jednym lub kilkoma serwisami, ale dokładnie te same pokrętła są w innych kryteriach akceptacji. Gdy mamy wersję jakąś super prostą, trochę bardziej skomplikowaną. Coś działa szybko, coś działa jeszcze szybciej. Czy na przykład są jakieś walidacje, albo ich nie ma? Gdzie wiadomo, że ta prostsza wersja to jest np. bez walidacji, albo z jakąś prostszą walidacji niż tą, którą wyobrażamy sobie jako docelową. To będzie oczywiście zawsze efekt rozmowy z całym zespołem, czy całego zespołu ze sobą. Gdzie tu jest w ogóle sens? Gdzie są te przerywane linie cięcia? Ale zazwyczaj ta długość kryteriów jest jakimś takim dosyć dobrym tropem, że jest tu coś możliwe do przecięcia. 

Jacek: I ostatnia porada, myślę, że nie będzie zaskoczeniem dla naszych stałych Słuchaczy. Mianowicie, usprawnij sposób wykorzystania kryteriów akceptacji z zespołem. Wykorzystywanie kryteriów akceptacji to jest pewien proces. Ten punkt startowy zespołu, to może być na przykład absolutna nauka od podstaw. Poznanie, czym w ogóle są kryteria akceptacji. No i stopniowe uczenie się, jak z nich korzystać. Stąd zakładam, że wykorzystujesz różne praktyki zwinne. Być może pracujesz w Scrumie. Wtedy Retrospektywa wydaje się być idealnym miejscem na głębszą refleksję na ten temat. Może to być jeden z punktów, który jest zgłoszony, po prostu jako obszar do przedyskutowania. Ale wyobrażam też sobie, że można by było zdecydować się na Retrospektywę tematyczną, gdzie z różnych kątów spojrzymy sobie wyłącznie na ten aspekt, jak operujemy kryteriami akceptacji i czy jest coś, co możemy w tym obszarze zrobić lepiej.

Kuba: I w temacie kryteriów akceptacji, w czasie, gdy pracuję coachingowo z zespołami, albo w czasie szkoleń, jest czasami taka pokusa – Powiedz nam, czy daj nam konkretną instrukcję, jak to robić perfekcyjnie. Jak to robić naprawdę dobrze. Daj nam gotowy szablon. Natomiast coś, co w praktyce w naturze spotykam, to to, że w zasadzie rzadko, żeby nie powiedzieć prawie wcale, nie spotykam zespołów, które natychmiast od zera, do stu procent super wykorzystania kryteriów, do tego dorastają. Tak naprawdę to jest kilka rundek, gdzie zaczynają od czegoś prostego. Później gdzieś tam dochodzimy do jakiegoś rodzaju perfekcji. Ale za każdym razem o tym rozmawiamy, za każdym razem przesuwamy sobie granice, dajemy sobie do zrozumienia, patrzymy na sprawy z różnej perspektywy. I druga przestroga związana z tym usprawnianiem, to same kryteria akceptacji są powiedziałbym, takim neutralnym tematem, że on może nie wyjść na światło dzienne, jeśli stosujemy pewien specyficzny rodzaj usprawniania się. Takie usprawnianie się od kryzysu do kryzysu. Czyli dopiero, gdy nam się nie uda wdrożenie, tylko dopiero, gdy nam się nie uda zrealizowanie Celu Sprintu, to dopiero wtedy gdzieś tam głębiej, czy poważniej o pewnych rzeczach rozmawiamy. W wielu zespołach tych kryzysów jest na tyle dużo, że tylko o kryzysach rozmawiamy, a nie rozmawiamy sobie jakimś takim codziennym, ciągłym doskonaleniu swojego działania. I te kryteria akceptacji, one często mają poważny wpływ na to, jak funkcjonuje cały zespół, ale wpływ ten jest pośredni. Czyli kryteria akceptacji pozwalają na lepsze sformułowanie tego, co jest do zrobienia, co jest celem, gdzie tu jest wartość. Co przekłada się później na efektywne wykorzystanie pracy całego zespołu. Na dostarczenie rozwiązania w gdzieś tam planowanych terminach, dobre jakości. Tylko często niestety jest tak, że bardziej się rozmawia o tym, jak poprawić jakość, a nie o tym, że dobre kryteria akceptacji mają na to wpływ. Albo jak poprawić terminowość, nie patrząc na to, że lepszy Backlog Produktu sprawiłby, że cały ten proces planowania, wyceniania i tak dalej, byłby lepszy. Innymi słowy, tą trochę przydługą częścią chcę powiedzieć to, że być może warto kryteriom akceptacji, całemu temu procesowi przejrzeć się, nawet jeśli nie czujemy, że jest tutaj jakaś wielka bolączka. Bo może się okazać, że ona jest schowana w tym takim pośrednim wianuszku. I my dużo uwagi przywiązujemy do rozwiązywania jakichś takich zewnętrznych objawów, a tak naprawdę poprawiając ten aspekt szeroko rozumianego Refinementu, czy konkretnie lepszego Backlogu Produktu i na przykład stosowania praktyki kryteriów akceptacji. To mogłoby nam pomóc, nawet jeśli na pierwszy rzut oka nie widzimy bezpośredniego związku.

Kuba: Podsumowując cały odcinek. Jakie mamy wskazówki, żeby dobrze zastosować kryteria akceptacji? Nie musisz mieć idealnych kryteriów przed rozmową z zespołem. Pisz kryteria akceptacji grupowo. Twórz kryteria, które są przydatne całemu zespołowi.

Jacek: Zaproś interesariuszy do tworzenia kryteriów. Nie wskazuj konkretnego sposobu implementacji. Obserwuj kryteria akceptacji pod kątem potencjalnych płaszczyzn cięcia i usprawniaj sposób wykorzystania kryteriów z zespołem.

Kuba: Usprawnianie sposobu funkcjonowania zespołu, to jeden z motywów, który wraca w case study’ies, który przygotowuję na warsztatach. I cała ta końcówka z ostatniej wskazówki jest mocno właśnie w tym guście. Tak naprawdę wiele zespołów, które ma swoje problemy różnego typu, które przepracowujemy w czasie warsztatów Prawdziwe Przypadki Scrumowe, często wraca właśnie do tego. A jak wyglądał ich Backlog? Jak podchodzili do kryteriów akceptacji? Czy czasami, by tego nie usprawnić? Ponownie jak w poprzednim odcinku podcastu zapraszam na warsztaty. Są jeszcze miejsca na 8-9 listopada w Warszawie na stacjonarnych warsztatach „Prawdziwe Przypadki Scrumowe”. Możliwość zapisania się, więcej informacji, co do ceny i do szczegółowych warunków, znajdziesz na stronie 202procent.pl/przypadki-scrumowe

Jacek: Ja gorąco zachęcam do udziału w warsztatach, które prowadzi Kuba. Natomiast notatki do tego odcinka, artykuł, transkrypcja oraz zapis wideo, znajdziesz na stronie porzadnyagile.pl/94

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek.

Jacek: Dzięki Kuba.

Kuba: I do usłyszenia wkrótce.