Kryteria akceptacji

Czym są kryteria akceptacji? Wiele osób stosuje tę praktykę zamiennie z Definicją Ukończenia, myląc je ze sobą. 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. Odpowiadają na pytanie, po czym poznasz, że zespół zrealizował to, co było oczekiwane. Co ważne, praktykę kryteriów akceptacji można stosować również poza Scrumem. Ten odcinek nie będzie zatem tylko “scrumowy”.

Czym są kryteria akceptacji i jak z nich skorzystać? Czym różnią się one od Definicji Ukończenia i dlaczego warto je prawidłowo określać?

Pytanie o różnicę między kryteriami akceptacji a Definicją Ukończenia słyszymy dość często, a z obserwacji wiemy, że wiele osób myli je lub stosuje zamiennie te podejścia. W artykule przedstawimy kryteria akceptacji w oparciu o przykłady z życia, a także podzielimy się z Tobą praktycznymi wskazówkami, jak z nich prawidłowo korzystać.

Ponieważ kryteria akceptacji to praktyka stosowana powszechnie, stąd też artykuł ten kierujemy nie tylko do społeczności scrumowej. Poza tym podręcznikowy Scrum nie wymaga stosowania kryteriów akceptacji, jako elementu obowiązkowego.

Kryteria akceptacji – definicja

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 jeszcze 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 sobie zespół i jego otoczenie odnośnie do tego, co ma zostać zrobione. 

Opisując to na przykładzie, wyobraźmy sobie sytuację, w której w trakcie rozwoju produktu czy realizowania projektu, dochodzimy do momentu, w którym chcemy porozmawiać o stworzeniu opcji logowania do aplikacji. W tym przypadku moglibyśmy ustalić sobie następujące kryteria akceptacji:

1. Hasło musi się składać z minimum 8 znaków.
2. Można się zalogować przy użyciu konta z innego serwisu.
3. Widoczna jest formłuka prawna o treści przygotowanej przez dział prawny (w realnej sytuacji tutaj powinna być konkretna treść tej formułki).
4. 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.
5. 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 tych kryteriów może i pewnie byłoby, więcej, tu jednak podajemy po prostu kilka przykładowych. Na tych kilku już jednak widać, że jedne kryteria mówią bardziej o zachowaniu systemu, drugie 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?

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ą, jak dobrze muszą być przygotowani do rozmowy z zespołem. Naszym zdaniem, wcale nie musisz znać wszystkich detali i szczegółów, żeby rozpocząć rozmowę. To właśnie rozmowa 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, i dopiero w toku pracy warsztatowej ustalicie wraz z zespołem na przykładach, co konkretnie to oznacza i jakie mamy możliwości techniczne.

Podobne dylematy mogą mieć też analitycy lub osoby wytypowane do optymalizacji Backlogu Produktu. Tutaj też przestrzegamy przed zbytnią ambicją w przygotowywaniu się do rozmowy, żeby przez przypadek Kryteria akceptacji nie stały się jakąś małą specyfikacją, z góry zdefiniowanego dokumentu bardzo szczegółowo rozpisane. Wtedy może zniknąć efekt współpracy, wspólnego odkrywania, rozumienia i dodawania stopniowo różnych elementów. 

2. Pisz kryteria akceptacji grupowo

Wspólna praca daje okazję do wykorzystania różnorodnych kompetencji, jakie są w  zespole. Wróćmy do przykładu z logowaniem. Product Owner czy np. jakiś interesariusz biznesowy wymyśla logowanie z opcją zapamiętania tego bez wylogowywania. Dzięki pracy grupowej osoba, która zna się dobrze na bezpieczeństwie, może wskazać minusy takiego rozwiązania i to kryterium może być zmienione, że sesja użytkownika jest pamiętana przez jeden dzień, a nie nieskończoność.

Rzecz jasna są kryteria, które są oczywiste i nie trzeba nad nimi zespołowo dywagować. Po prostu ważne jest zrozumienie, kiedy warto zaangażować zespół, aby zobaczyć inną perspektywę czy odkryć inny sposób zrealizowania jakiejś potrzeby lub rozwiązania konkretnego problemu.

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

Zwykle zespoły, które pracują zwinnie, są tak skonstruowane, że posiadają wewnątrz sporo kompetencji, aby ograniczyć zależności zewnętrzne i żeby od samego początku mieć takie holistyczne spojrzenie na produkt. Stąd warto, aby każdy mógł dołożyć cegiełkę ze swojego obszaru kompetencji. Da to większą pewność, że nic nam nie umknęło. 

Niestety często widzimy zespoły, które całkiem nieźle podchodzą do kryteriów akceptacji, ale widzą je tak, jakby tylko z jednej perspektywy, zwykle z perspektywy programistów. Przez to może być tak, że mimo że kryteria akceptacji są rozległe, to jednak nie dają testerom możliwości stworzenia scenariuszy i wykonania ich pracy. Dlatego rekomendujemy podejście, w którym dbamy, żeby o przydatność kryteriów dla całego zespołu. Może to oznaczać odrobinę kompromisów i otwarcie się na potrzeby całego zespołu.

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

Interesariuszami może być wiele osób, np. przedstawiciele użytkownika, przedstawiciele biznesowi, klient, jakiś konkretny ekspert albo inny zespół z firmy. Dlaczego warto ich zaprosić? Wyobraźmy sobie przykład z logowaniem i formułka prawną. Jak dokładnie ta formułka ma brzmieć? Możemy wysłać prośbę do prawnika, aby przygotował jej treść i ją po prostu wklejamy, tworząc trochę taki głuchy telefon. Możemy też przygotować coś sami i dać do zaakceptowania prawnikowi. Natomiast naszym zdaniem najlepiej zaprosić tego prawnika do rozmowy, opowiedzmy mu o naszym produkcie, czego potrzebujemy, jakie są różne tego wymiary. To da wszystkim lepsze zrozumienie tematu, a także działamy po prostu w duchu współdziałania, komunikacji i uwzględniania różnych perspektyw.

Może też się pojawić pokusa, żeby to Product Owner lub inny reprezentant biznesowy poszedł do interesariusza i to załatwiał. Tak naprawdę tylko pozornie optymalizujemy pracę, natomiast po drodze jest masa szumu i możliwych przeinaczeń, co w końcowym efekcie może być przyczyną błędów, które trzeba przegadać, znów skonsultować i poświęcać na to czas. Zatem o wiele lepiej zastanowić się kogo możemy zaprosić na sesję, podczas której kształtujemy kryteria akceptacji, aby nam po prostu pomógł.

5. Nie wskazuj konkretnego sposobu implementacji

To często obserwowana przez nas pokusa, żeby kryteria akceptacji prowadziły zespół do konkretnego rozwiązania. W przykładzie z logowaniem mogłoby się pojawić bardzo konkretne wskazanie, gdzie dokładnie, jeśli chodzi o interfejs użytkownika, powinna się pojawić ta formułka prawna, w sytuacji, gdzie nie ma to tak naprawdę znaczenia. To gdzie ona zostanie umiejscowiona, powinien wypracować zespół. Wszelkie pomysły mocno zawężające pole do działania, 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. Mocno przestrzegamy przed taką zbytnią konkretyzacją, która może wynikać z dobrych intencji ułatwienia komuś pracy i pokazania, że dokładnie wiemy, czego potrzebujemy. Warto się zastanowić jak bardzo, to co formułujemy, jest autentycznym kryterium akceptacji, a jak to takie uproszczenie lub sugerowanie jedynej słusznej drogi, która wcale nie musi być najwłaściwsza.

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

Mamy na myśli tutaj, że generalnie 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 usunąć, albo dostarczyć na początku w trochę prostszej wersji. I warto poświęcić czas na poszukiwanie tych płaszczyzn cięcia, gdyż jest  to jeden z takich dużych atutów podejścia zwinnego. Znów 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 jest pewien proces. 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ę jak operujemy kryteriami akceptacji i czy jest coś, co możemy w tym obszarze zrobić lepiej. Z doświadczenia wiemy, że żaden zespół nie korzysta z kryteriów akceptacji na 100%. Wymaga to praktyki i stopniowego zgłębiania tematu.

Na koniec chcemy podkreślić, że kryteria akceptacji często mają duży wpływ na to, jak funkcjonuje cały zespół. Wpływ ten jest jednak pośredni. Kryteria akceptacji pozwalają na lepsze sformułowanie tego, co jest do zrobienia, co jest celem, gdzie jest wartość. Przekłada się to później na efektywne wykorzystanie pracy całego zespołu i na dostarczenie rozwiązania w dobrej jakości i w terminie. 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, byłby lepszy. Innymi słowy, warto częściej przyglądać się kryteriom akceptacji, nawet jeśli nie czujemy, że jest tutaj jakiś wielki problem. Bo może się okazać, że jest on schowany w pośredniej szufladce. Przez zbyt dużo uwagi przywiązujemy do rozwiązywania zewnętrznych objawów, zamiast poprawić stosowanie kryteriów akceptacji, czy aspekt szeroko rozumianego Refinementu. 

Dodatkowe materiały

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

TRANSKRYPCJA

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. No 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.