Definicja

Acceptance Criteria (Kryteria Akceptacji) to zestaw konkretnych wymagań, które precyzują zakres User Story. Podczas gdy sama opowieść użytkownika opisuje cel i wartość, kryteria akceptacji definiują “warunki brzegowe” – czyli co dokładnie musi się dziać, aby rozwiązanie zostało uznane za działające.

Cel stosowania AC

Kryteria akceptacji pełnią kilka kluczowych funkcji w procesie wytwórczym:

  • Usuwanie niejasności: Uszczegóławiają User Story, eliminując domysły zespołu deweloperskiego.
  • Podstawa do testów: Stanowią fundament do tworzenia scenariuszy testowych i testów automatycznych.
  • Wspólne zrozumienie: Gwarantują, że Product Owner i zespół mają tę samą wizję “sukcesu” dla danego zadania.

Formaty zapisu

Istnieją dwa najpopularniejsze sposoby zapisywania kryteriów akceptacji:

1. Lista kontrolna (Checklista)

Proste punkty opisujące zachowanie systemu.

  • Przykład: “Hasło musi mieć minimum 8 znaków”, “System wysyła e-mail potwierdzający”.

2. Format Given-When-Then (Gherkin)

Bardziej ustrukturyzowany format, idealny do testów automatycznych:

  • Given (Mając): Kontekst/stan początkowy.
  • When (Gdy): Akcja użytkownika.
  • Then (Wtedy): Oczekiwany rezultat.
  • Przykład: Given użytkownik jest na stronie logowania, When wpisze poprawne dane, Then zostaje przekierowany do panelu głównego.

AC a Definition of Done (DoD)

Częstym błędem jest mylenie tych dwóch pojęć, mimo że oba służą weryfikacji jakości:

Cecha Acceptance Criteria (AC) Definition of Done (DoD)
Zastosowanie Unikalne dla każdego zadania/User Story. Uniwersalne dla każdego zadania w zespole.
Przykłady “Przycisk jest czerwony”, “Walidacja NIP”. “Kod przeszedł review”, “Testy zaliczone”.
Kiedy sprawdzane? Podczas testowania konkretnej funkcji. Przed uznaniem zadania za ukończone (Inkrement).

Typowe błędy

  • ❌ Zbyt techniczny język – AC powinny być zrozumiałe dla biznesu, a nie opisywać nazwy tabel w bazie danych.
  • ❌ Zbyt ogólne sformułowania – Np. “System powinien być szybki” (brak możliwości obiektywnego przetestowania).
  • ❌ Opisywanie UI zamiast zachowania – Skupianie się na pixelach zamiast na logice biznesowej, co ogranicza kreatywność zespołu.

Podsumowanie

Kryteria akceptacji to “punkt styku” między wymaganiem biznesowym a techniczną realizacją. Dobrze sformułowane AC są kluczowym elementem Definition of Ready (DoR), ponieważ bez nich zespół nie jest w stanie rzetelnie oszacować złożoności zadania ani zaplanować jego realizacji w sprincie.

Powiązane pojęcia:

Kliknij w pojęcie, aby przejść do jego definicji w słowniku