Kryteria Akceptacji User Story - czym sa i jak je formułować?

User Story to narzędzie pozwalające zogniskować pracę zespołu na zaspokojeniu potrzeb użytkownika. Kryteria akceptacji User Story służą do sprawdzania, czy nowa funkcjonalność Produktu jest w pełni sprawna i satysfakcjonująca z punktu widzenia użytkownika.

Kryteria Akceptacji User Story – omówione zagadnienia:

Wprowadzenie
Jak sformułować kryteria akceptacji?
Kryteria akceptacji a Definicja Ukończenia
Podsumowanie

Wprowadzenie

O tym, czym jest User Story, a także o tym, jakie problemy mogą pojawiać się przy jej przygotowaniu, pisaliśmy w poprzednich artykułach. Dziś natomiast skupimy się na kryteriach akceptacji User Story.

Kryteria akceptacji spełniają następujące warunki:

opisują nowe, ulepszone działanie Produktu z punktu widzenia użytkownika
są unikatowe dla każdej User Story.

User Story ani kryteria jej akceptacji nie zostały zdefiniowane w oficjalnym Przewodniku po Scrumie. Są one bowiem opcjonalnymi, choć bardzo często używanymi elementami pracy w Scrum. Dlatego na potrzeby tekstu zdefiniujemy kryteria akceptacji jako:

warunki, jakie musi spełniać udoskonalenie Produktu wykonane w danym Sprincie, aby mogło zostać zaakceptowane przez Użytkownika.

Jak sformułować kryteria akceptacji?

Dobrze napisana User Story zawiera jasny opis sytuacji, w której zostaje zrealizowana. Czyli zawiera swoje kryteria akceptacji. User Story jest jednak często bardzo krótkim zdaniem, które często można interpretować na różne sposoby.

Jasność i dostępność kryteriów akceptacji

Dlatego aby zapobiec niejasnościom, konieczne jest przeprowadzenie szczegółowej rozmowy z Klientem i ustalenie celu realizowanego rozwiązania. Ostateczne sformułowanie kryteriów akceptacji należy jednak do Product Ownera.

Muszą one zostać spisane przed włączeniem User Story do Sprint Planning. Każdy z członków Scrum Team musi się z nim zapoznać i potwierdzić, że rozumie i zgadza się z przedstawionymi kryteriami akceptacji User Story. Zwykle kryteria akceptacji zostają zapisane po drugiej stronie karty z User Story.

Właściwie sformułowane kryteria akceptacji sprawiają, że użytkownik może sprawdzić, czy User Story została zrealizowana po prostu używając produktu w opisany przez nią sposób. Mogą przyjmować formę checklisty, której punkty zostaną oznaczone jako wykonane przy testach Produktu na koniec Sprintu.

Sprawa jest prosta, jeśli działanie Produktu jest przejrzyste dla użytkownika. Jednak efektywne sprawdzenie złożonych produktów może okazać się trudne. Przykładem może być skomplikowane oprogramowanie lub usługi świadczone na szeroką skalę. Dlatego w większości przypadków przydatnym narzędziem do sprawdzenia poprawności User Strory jest przygotowanie testu akceptacyjnego.

Test akceptacyjny

Jeśli test akceptacyjny zostaje opracowany, jest on zapisywany w miejscu kryteriów akceptacji, czyli na rewersie karty zawierającej User Story. Może on zostać przeprowadzony przez Scrum Team bądź przez zewnętrzny zespół QA.

Test akceptacyjny musi przede wszystkim zawierać jasne określenie, czy Produkt Nie Przeszedł/Przeszedł test. Nie może zawierać określeń procentowych lub stanów pośrednich.

Jeśli User Story zawiera więcej niż jedno kryterium akceptacji, każde z nich powinno być testowane niezależnie. Dzięki temu znacznie łatwiej określić, która funkcjonalność produktu wymaga poprawy lub dopracowania. Jest to szczególnie istotne, jeśli nowe funkcjonalności zawarte w User Story zazębiają się lub są od siebie zależne.

Kryteria akceptacji a Definicja Ukończenia

Definition of Done jest integralną częścią pracy w Scrum, która jest technicznym odpowiednikiem kryterium akceptacji. Spełniają one jednak odmienne role i nie należy ich ze sobą mylić. Temu, czym jest Definicja Ukończenia, jak i kiedy ją sformułować, poświęciliśmy więcej miejsca w osobnym wpisie.

Tutaj wspomnimy tylko, że Definicja Ukończenia to zamieszczony w Backlogu Produktu jasny i przejrzysty opis oczekiwanego stanu Produktu po ukończeniu Przyrostu. Opisuje on ulepszenia dokonane w ramach Przyrostu. W odróżnieniu od kryterium akceptacji odpowiadającemu User Story, które opisuje funkcjonalność Produktu stworzoną podczas ostatniego Sprintu tak, jak jest ona postrzegana przeze Klienta.

Przykładowo, weźmy User Story o treści:

Jako zalogowany klient sklepu internetowego chcę kupić magiczną różdżkę za pomocą jednego kliknięcia.

Definicja Ukończenia dla powyższej User Story może zawierać następujące elementy:

stworzenie panelu logowania dla klientów sklepu
integracja systemu płatności
dodanie przycisku natychmiastowej płatności do szablonu strony produktu.

Natomiast kryterium akceptacji przez Klienta będą następujące:

możliwość zalogowania się do sklepu
możliwość zdefiniowania domyślnej metody płatności
działający przycisk „Kup teraz” przy produkcie „magiczna różdżka”.

Podsumowanie

Kryterium akceptacji to sposób na ocenę realizacji User Story. Opisuje nowe, ulepszone działanie Produktu z punktu widzenia użytkownika. Jest ono bardzo ważnym narzędziem pracy z Klientem. Przedstawia bowiem wykonanie zadania przez Scrum Team z jego punktu widzenia.

Dobrze sformułowane kryteria akceptacji, na przykład w formie testu akceptacyjnego, pozwalają też sprawdzać w trakcie Sprintu, czy tworzona funkcjonalność zmierza w kierunku spełnienia wymogów Klienta.

Kryteria akceptacji różnią się od Definicji Ukończenia przede wszystkim perspektywą, z jakiej są wyrażane. Nie zawierają bowiem opisu technicznych wymogów, które powinno spełniać nowe rozwiązanie., a jedynie funkcje, jakie ma spełniać produkt po realizacji nowej User Story.

Sprawdź kolejny wpis z tej serii: Estymacja i Story Points w Scrum

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Zobacz wszystkie posty

Przerwa konserwacyjna

Scrum Guide | 22. Kryteria Akceptacji User Story