Przewodnik po Scrumie | 22. Kryteria akceptacji historii użytkownika

User Story to technika pozwalająca firmom na dostarczanie produktów i usług maksymalnie spełniających potrzeby klientów. Kryteria akceptacji User Story usprawniają ocenę nowych funkcjonalności Produktu z punktu widzenia użytkownika.

Kryteria akceptacji historyjek użytkownika – spis treści:

1. Wstęp
2. Jak sformułować kryteria akceptacji User Story?
3. Kryteria akceptacji historii użytkownika a definicja ukończenia
4. Streszczenie

Wstęp

W poprzednich artykułach omówiliśmy historię użytkownika i problemy, które należy rozwiązać po jej stworzeniu. Dziś jednak skupimy się na kryteriach akceptacji User Story.

Kryteria akceptacji powinny być zgodne z następującymi wytycznymi:

• opisać nową i ulepszoną funkcjonalność Produktu z punktu widzenia użytkownika;
• być unikalnym dla każdego User Story

Oficjalny Przewodnik Scrum nie definiuje User Story i kryteriów jej akceptacji. Są to opcjonalne, ale bardzo powszechne elementy pracy Scrum. Jednak, aby rozładować ciekawość naszych czytelników, przedstawimy je jako: Warunki, jakie musi spełnić ulepszenie Produktu podczas danego Sprintu, aby uzyskać akceptację Użytkownika.

Jak sformułować kryteria akceptacji User Story?

Dobrze napisana User Story zawiera jasny opis kontekstu lub sytuacji, której dotyczy, spełniając tym samym kryteria akceptacji. Jest to jednak tylko krótkie zdanie, zbyt niejasne i niejednoznaczne, aby wprost wskazać konieczne rozważania.

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

Dlatego, aby zapobiec niejasnościom, przeprowadź i nagraj szczegółową rozmowę z klientem w celu ustalenia celu wdrożonego rozwiązania. Pamiętaj, że ostateczne sformułowanie kryteriów akceptacji należy do Product Ownera.

Zapisz je razem z kryteriami User Story przed planowaniem sprintu. Każdy członek Zespołu Scrumowego musi go przeczytać i potwierdzić, że rozumie i zgadza się z kryteriami akceptacji User Story. Zazwyczaj kryteria akceptacji znajdują się po drugiej stronie karty User Story.

Odpowiednio sformułowane kryteria akceptacji pozwalają użytkownikowi sprawdzić, czy testowanie User Story jest zgodne z jego opisem. Kryteria mogą mieć formę listy kontrolnej z punktami do zaznaczenia, gdy zostaną wypełnione podczas testowania Produktu na koniec Sprintu.

Sprawa jest prosta, jeśli działanie Produktu jest przejrzyste dla Użytkownika. Jednak im bardziej złożony produkt, tym trudniej go przetestować. Weźmy na przykład złożone oprogramowanie lub usługi na dużą skalę. Dlatego w większości przypadków przydatnym narzędziem do walidacji User Story jest przygotowanie testu akceptacyjnego.

Test akceptacyjny

Jeśli zdecydujesz się opracować test akceptacyjny, odłóż go na drugą stronę karty zawierającej User Story. Później może to przeprowadzić Zespół Scrumowy lub zewnętrzny zespół QA.

Test musi przede wszystkim zawierać jasne stwierdzenie , czy Produkt nie przeszedł pomyślnie testu. Nie może zawierać oświadczeń procentowych ani oceny pośredniej.

Jeśli User Story ma więcej niż jedno kryterium akceptacji, każde wymaga osobnego testowania. W ten sposób znacznie łatwiej jest określić, która funkcjonalność produktu wymaga poprawy lub dopracowania i jest to szczególnie ważne, gdy nowe funkcjonalności zawarte w User Story nakładają się lub są od siebie niezależne.

Kryteria akceptacji historii użytkownika a definicja ukończenia

Definicja Ukończenia jest integralną częścią pracy w Scrum, która jest technicznym odpowiednikiem kryteriów akceptacji. Nie należy jednak mylić tych dwóch, ponieważ oznaczają one różne zobowiązania. Jaka jest definicja ukończenia oraz jak i kiedy ją sformułować, to kwestia, którą omówiliśmy w osobnym poście?

W tym miejscu nadmienimy tylko, że Definicja Ukończenia jest jasnym i przejrzystym opisem oczekiwanego stanu Produktu po zakończeniu Przyrostu w Backlogu Produktu. Opisuje ulepszenia wprowadzone w ramach Przyrostu. Stoi to w sprzeczności z kryterium akceptacji odpowiadającym User Story, które opisuje funkcjonalność Produktu stworzoną podczas ostatniego Sprintu tak, jak jest postrzegana przez Klienta.

Weźmy na przykład tę Historię użytkownika z treścią:

Jako zalogowany klient sklepu internetowego chcę jednym kliknięciem kupić magiczną różdżkę.

Definicja Dokończenia powyższej Historii Użytkownika może obejmować:

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

Z drugiej strony kryteria akceptacji klienta obejmują:

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

Streszczenie

Kryteria akceptacji to zbiór warunków, które służą do oceny realizacji User Story. Opisując nowe i ulepszone działanie Produktu z punktu widzenia użytkownika, metoda ta staje się skutecznym narzędziem pracy z Klientem. Przedstawia wydajność Zespołu Scrumowego z punktu widzenia użytkownika.

Dobrze sformułowane kryteria akceptacji, np. w formie testu akceptacyjnego, pozwalają nam również sprawdzić w trakcie Sprintu, czy stworzona funkcjonalność usprawnia spełnienie wymagań Klienta.

Kryteria akceptacji różnią się od Definicji Ukończenia przede wszystkim perspektywą, jaką przyjmują na wyrażenie. Nie zawierają opisu wymagań technicznych, jakie powinno spełniać nowe rozwiązanie, a jedynie funkcje, jakie powinien posiadać produkt po zaktualizowaniu nowego User Story.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

1. Słowniczek podstawowych pojęć, ról i pojęć
2. Co to jest Scrum?
3. Wartości Scrum
4. Jak wdrożyć Scrum w swojej firmie?
5. Zespół Scrumowy - co to jest i jak działa?
6. Kim jest Product Owner?
7. Najczęstsze błędy Product Ownera
8. Kim jest Scrum Master?
9. Charakterystyka dobrego Scrum Mastera
10. Najczęstsze błędy Scrum Mastera
11. Jakie statystyki i metryki powinien śledzić Scrum Master?
12. Współpraca Product Ownera ze Scrum Masterem
13. Zespół Deweloperski w Scrum
14. Najczęstsze błędy programistów
15. Artefakty Scrum
16. Skalowanie Scrum
17. Backlog Sprintu
18. Czym jest Backlog Produktu?
19. Czym są historie użytkowników?
20. Tworzenie najlepszej historii użytkownika z INVEST
21. Najczęstsze błędy User Story
22. Kryteria akceptacji historii użytkownika
23. Szacowanie i punkty fabularne w Scrumie
24. Poker Planowania
25. Drużynowa gra szacowania
26. Definiowanie przyrostu
27. Wydarzenia scrumowe
28. Czym jest Sprint w Scrumie?
29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
30. Co to jest wykres spalania?
31. Jak stworzyć i zinterpretować wykres spalania?
32. Zalety i wady wykresu spalania
33. Tablice Kanban w Scrum i Scrumban
34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
35. Codzienny Scrum
36. Planowanie sprintu
37. Przegląd sprintu
38. Czym jest retrospektywa sprintu?
39. Typowe błędy podczas Retrospektywy Sprintu
40. Pielęgnacja Backlogu Produktu