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:

  1. Wprowadzenie
  2. Jak sformułować kryteria akceptacji?
  3. Kryteria akceptacji a Definicja Ukończenia
  4. 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.

User Story Acceptance Criteria

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.

Scrum Guide | 22. Kryteria Akceptacji User Story caroline becker avatar 1background

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ść.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?