Skip to content

Kryteria akceptacji – jak bardzo powinny być szczegółowe?

Kryteria akceptacji (ang. acceptance criteria) to lista wymagań, które należy spełnić, aby historyjka użytkownika mogła zostać uznana za gotową z biznesowego punktu widzenia. Powinny zostać utworzone przez cały zespół scrumowy, na podstawie tego, czego oczekuje klient, najczęściej za pośrednictwem Product Ownera. Czy nie lepiej więc, jeśli zostaną przez niego zdefiniowane od razu szczegółowo i technicznie, aby zaoszczędzić czas?

Kiedy uszczegóławiać kryteria akceptacji?

Product Owner powinien powiedzieć zespołowi co i dlaczego należy wykonać, ale nie powinien już na początku określać wszystkich możliwych szczegółów. Znacznie lepsze wymagania mogą zostać utworzone wspólnie przez cały zespół scrumowy podczas refinementu. Efektem tego procesu powinny być bardziej szczegółowe acceptance criteria, początkowy zestaw nie musi zawierać ich zbyt wiele.

Ostatnim momentem na dokonywanie zmian w kryteriach akceptacji powinno być planowanie sprintu. Potrzebę klienta powinniśmy rozumieć całym zespołem, zanim zaczniemy pracować nad zadaniem. Nie oznacza to, że nie możemy dokonać jakiejś korekty w trakcie sprintu. Należy jednak być z tym bardzo ostrożnym, w końcu podczas planowania określiliśmy zakres historyjki, więc większe zmiany mogą spowodować komplikacje.

Jak wyglądają zbyt szczegółowe acceptance criteria?

Wyobraźmy sobie następującą sytuację – Product Owner przychodzi do zespołu deweloperskiego z następującą historyjką dotyczącą listy zakupów w tworzonej aplikacji:

Jako przeglądający listę zakupów chcę kolorowego rozróżnienia wierszy na liście dla owoców i warzyw, abym mógł znaleźć jeden typ produktu przy wizycie na konkretnym stoisku.

Kryteria akceptacji:

  • Rozdzielić obecną kategorię “Warzywa i owoce” na dwie osobne
  • Na liście produktów warzywa powinny mieć kolor #FFAB68
  • Na liście produktów owoce powinny mieć kolor #4A49FF

Jest to trochę przerysowany przykład, ale czy nie zdarzyło się wam oglądać tego typu historyjek w waszych backlogach?

Zadanie wygląda na przemyślane przez Product Ownera, wszystko zostało dokładnie opisane. Jednak czy tak określone wymagania spowodują dostarczenia wartościowego przyrostu? Czy Product Owner nie posunął się za daleko, definiując nie tylko “co”, ale wkroczył już w zakres “jak”?

Być może rozwiązanie określone za pomocą kryteriów akceptacji wcale nie jest właściwe. Może typów produktów jest już tyle, że lepiej zastosować ikony? A może po prostu posortować poszczególne produkty kategoriami zamiast dodawać kolejne kolory?

Kłopot polega na tym, że tak szczegółowo zdefiniowana historyjka, umieszczona w backlogu, może już w nim pozostać bez zmian.

Dlaczego zespół deweloperski może lubić szczegółowe kryteria akceptacji?

To może być duża oszczędność czasu. Po co mamy spędzać czas i dyskutować o szczegółach, skoro i tak Product Owner o wszystkim powinien wiedzieć, bo jest ekspertem domenowym? W końcu to on rozmawiał z klientem lub stakeholderami, może zatem wszystko dokładnie opisać.

Niestety, takie podejście może być bardzo zdradliwe. Podczas refinementu lub planowania, szczególnie mniej doświadczony zespół, może po prostu zgodzić się na realizację i nie zastanowić nad konsekwencjami kryteriów akceptacji. Takie coś doprowadzi do stworzenia przyrostu, który nie do końca odpowiada on potrzebom klienta

Dlaczego tak się mogło stać?

Porozmawiajmy o szczegółach… ale w sumie po co?

Pierwszym negatywnym następstwem szczegółowych kryteriów akceptacji jest zamykanie dyskusji. Proces doskonalenia rejestru produktu polega właśnie na rozmowie, analizie oraz dodawaniu większych detali. Jeśli Product Owner już to wcześniej zrobił, deweloperzy nie mają potrzeby robić więcej, niż co najwyżej podzielić oraz wyestymować dane zadanie. Konsekwencje tego mogą być różne.

Czy Product Owner zawsze ma najlepszy pomysł?

Jeśli na sali spotka się kilka osób, zapewne wpadną oni wspólnie na lepszy pomysł, niż jedna. Nawet, jeśli jest ekspertem. Na pewno przeanalizują problem z różnych perspektyw, pomyślą o warunkach brzegowych.

Taka właśnie sytuacja powinna mieć miejsce podczas refinementu. Product Owner nie zawsze wpadnie na najlepsze rozwiązanie, głos deweloperów może mu pomóc w jego znalezieniu.

Ważną kwestią jest to, że Produkt Owner może nie znać technicznych aspektów tworzenia rozwiązania. Bez pomocy zespołu może więc chcieć stworzyć bardzo pracochłonne rozwiązanie, pomijając inne, znacznie łatwiejsze w wykonaniu.

Product Owner też może się pomylić!

Dyskusja może także pomóc w znalezieniu potencjalnych błędów. Gdy mamy bardzo dokładnie zdefiniowaną listę wymagań, przestajemy zwracać uwagę na szerszy kontekst. W końcu, skoro Product Owner tak wszystko dobrze opisał, to musiał wszystko przemyśleć. 

Biorąc to pod uwagę, deweloperzy mogą nie zwrócić uwagi na błędy, jakie mógł popełnić Product Owner.

Brak zrozumienia potrzeby użytkownika

Duża liczba szczegółów powoduje także, że na dalszy plan schodzi myślenie o potrzebach użytkownika. Zespół deweloperski przestaje myśleć o powodach, dla których tworzy daną historyjkę, a skupia się tylko na wykonaniu poszczególnych punktów zapisanych w acceptance criteria.

Kryteria akceptacji mogą zmniejszyć odpowiedzialność zespołu

Kolejnym negatywnym następstwem zbyt szczegółowych kryteriów akceptacji może być traktowanie całych zadań jako kolejne skreślenia z listy, bez skupienia na problemie. Poczucie współtworzenia zostaje mocno ograniczone, a zespół deweloperski zaczyna traktować poszczególne historyjki jako zadania zlecone przez Product Ownera, a nie coś tworzonego wspólnie.

Trzeba zachować równowagę

Jakie więc podejście najlepiej zastosować w przypadku kryteriów akceptacji? Jak to w życiu, najlepiej ani za dużo, ani za mało szczegółów. Zespół deweloperski powinien zrozumieć i wiedzieć, czego się od niego oczekuje. Czasami wystarczy do tego dobrze zdefiniowane User Story, a szczegóły można doprecyzować wspólnie.

Jeśli acceptance criteria zostaną one zdefiniowane zbyt szczegółowo, możemy pozbawić się zalet wynikających ze wspólnego tworzenia wymagań przez cały zespół scrumowy.

Published inAgile

Be First to Comment

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *