Narzędzia
Portfolio Roadmapa Słownik Blog Portal dla BA
← Słownik
Wymagania

Acceptance Criteria

Kryteria akceptacji to konkretne warunki, które muszą być spełnione, żeby uznać, że dane zadanie (np. nowa funkcja w programie) zostało wykonane prawidłowo. Używa się ich, żeby wszyscy wiedzieli, co dokładnie trzeba zrobić i kiedy można powiedzieć, że praca jest skończona. Na przykład, kryterium akceptacji dla formularza logowania może być: "Użytkownik musi mieć możliwość zalogowania się, używając poprawnego adresu email i hasła".

Definicja

Acceptance Criteria - patrz: Kryteria akceptacji

To angielska nazwa kryteriów akceptacji. W praktyce pojęcia używane zamiennie, szczególnie w międzynarodowych zespołach Agile.

Formaty (powtórzenie)

Given/When/Then (Gherkin)

Scenario: Successful login
  Given the user is on the login page
  When they enter valid credentials
  Then they see the dashboard

Rule-based

- Email field validates format (must contain @)
- Password minimum 8 characters
- 3 failed attempts locks account for 15 minutes

Dlaczego to ważne?

Termin pojawia się w BABOK, Scrum Guide i praktycznie każdym narzędziu (Jira, Azure DevOps). BA musi biegle posługiwać się oboma wersjami.

Powiązane pojęcia

Dlaczego w słowniku stoją dwa hasła o jednej rzeczy

Na 261 opublikowanych haseł tego słownika to jedyne, które zaczyna się od formuły „patrz:" i odsyła do polskiego bliźniaka (odczyt bazy 22.09.2026). To nie jest przeoczenie redakcyjne. Tak wygląda codzienność polskiego zespołu: historyjka napisana po polsku, rozmowa na refinemencie po polsku, a w środku scenariusza stoi angielskie „Given", bo tak nazywa się ta część formatu w narzędziach, w których się ją zapisuje - od Jiry po Azure DevOps.

Dwa hasła stoją obok siebie, bo obie formy trafiają do wyszukiwarki i stoją za nimi dwie różne potrzeby. Jeśli wpisujesz „kryteria akceptacji", zwykle chcesz wiedzieć, co to jest i jak to napisać - i tam prowadzi kryteria akceptacji, a warsztat pisania stoi we wpisie kryteria akceptacji - jak pisać. Jeśli wpisujesz „acceptance criteria", prawdopodobnie masz ten termin już przed oczami: w polu w narzędziu, w mailu od klienta, w dokumencie od zespołu z innego kraju. Potrzebujesz czegoś innego - pewności, że dobrze go czytasz i dobrze nazywasz.

I o tym jest reszta tego hasła: o angielskiej warstwie terminu. O gramatyce, o sąsiadach, o kalkach i o decyzji, w którym języku prowadzić artefakt. Warsztat pisania kryteriów od zera został w tekście, do którego link stoi akapit wyżej.

„Criteria" czy „criterion"? Jedna litera, która zmienia sens

„Criteria" to liczba mnoga. Liczba pojedyncza brzmi „criterion". Polskie „kryterium akceptacji" to po angielsku „an acceptance criterion", a nie „an acceptance criteria". Z naszej praktyki: to pomyłka, którą w dwujęzycznych backlogach widuje się regularnie.

Dlaczego to ma znaczenie, skoro wszyscy i tak zrozumieją? Bo termin prawie nigdy nie występuje w liczbie pojedynczej przypadkiem. Jedno z fundamentalnych zdań o tym artefakcie brzmi: jedno wymaganie ma wiele kryteriów. Tak to stawia lekcja 05 naszego minikursu o wymaganiach: „one requirement -> many criteria", bo trzeba pokryć różne sytuacje - normalną, brak danych, odwołanie, awarię. Kiedy piszesz „one acceptance criteria", zacierasz dokładnie tę relację, o którą chodzi. Liczba mnoga w nazwie przypomina, że kryteriów ma być kilka.

Jak wygląda to samo kryterium po polsku i po angielsku?

Nasz glosariusz tłumaczeń kursów ustala parę kanoniczną wprost: „kryteria akceptacji -> acceptance criteria" (sekcja „Wymagania"). To jedna z tych par, które tłumaczą się jeden do jednego, bez pułapki znaczeniowej. Inaczej niż „analityka biznesowa", która w znaczeniu BI tłumaczy się na „business intelligence", a nie na „business analytics" - i ten sam glosariusz osobno tego pilnuje.

Sama struktura zdania też ma dwa obiegi. Po angielsku: Given, When, Then. Po polsku: Zakładając, Kiedy (albo Gdy), Wtedy. To ten sam format w dwóch językach - i tak go podajemy na forum przy rozbiórce historyjki o resetowaniu hasła: „Zakładając / Kiedy / Wtedy (pewnie kojarzysz to jako Given / When / Then)".

Szablon z angielskiej wersji tej samej lekcji wygląda tak:

Criterion [name] - for requirement: "..."
  Given  <starting state: who, which case, what data>
  When   <trigger: which event>
  Then   <concrete result: what the system does>

Po polsku szkielet jest identyczny, zmieniają się tylko etykiety:

Kryterium [nazwa] - do wymagania: "..."
  Zakładając  <stan początkowy: kto, jaka sprawa, jakie dane>
  Kiedy       <wyzwalacz: jakie zdarzenie>
  Wtedy       <konkretny rezultat: co robi system>

Czy trzeba pisać po angielsku? Nie. Odpowiedź, którą dajemy od dawna, brzmi: słowa kluczowe pochodzą z angielskiego, bo przyszły z narzędzi BDD, ale treść scenariuszy pisz w języku, którym mówi zespół. Ważna jest struktura, nie język. Rozwinięcie tego wątku wraz z przykładami stoi we wpisie o pisaniu kryteriów akceptacji.

Jak czytać cudze acceptance criteria, gdy wchodzisz na projekt w trakcie?

Wchodzisz na trwający projekt, otwierasz backlog i widzisz pole wypełnione po angielsku. Dwie pułapki są tu czysto językowe i w polskiej wersji tekstu po prostu nie występują.

Pierwsza to liczba mnoga w nazwie pola. Jeśli pod nagłówkiem „Acceptance Criteria" stoi jedno zdanie, to zwykle nie znaczy, że wymaganie jest proste. Znaczy, że ktoś opisał ścieżkę, na której wszystko poszło dobrze, i na tym skończył.

Druga to angielskie słowa-wytrychy. Lekcja 05 minikursu o wymaganiach wymienia mgliste kryteria wprost: „the system sends the SMS correctly", „the feature works as expected", „the interface is intuitive" to nie są kryteria, tylko życzenia w przebraniu. Z obserwacji: angielszczyzna dokłada do tej listy własne odmiany - „properly", „as designed", „accordingly". Każde z nich czytaj jak polskie „poprawnie", czyli jak sygnał, że ktoś nie dokończył myśli.

Reszta sprawdzenia nie zależy już od języka: kompletność trzech części, obecność ścieżki błędu, test jednoznaczności. Pełna lista testów jakości kryteriów stoi we wpisie o pisaniu kryteriów akceptacji.

Jedno jeszcze o samym języku. Kryterium napisane kulawym angielskim, ale jednoznaczne, jest lepsze od eleganckiego zdania, którego nie da się sprawdzić.

Jak nazwać pole na kryteria w dwujęzycznym zespole?

Tu nie ma reguły branżowej, jest decyzja zespołu - i lepiej podjąć ją raz niż podejmować ją co sprint. W naszym materiale o Jirze i Confluence dla analityka pole własne dla historyjki nazywa się po polsku „Kryteria akceptacji", a format w środku jest angielski, czyli Given-When-Then. To jest świadomy podział: etykieta w języku zespołu, składnia w języku formatu.

Zasada, którą stosujemy przy tłumaczeniach własnych materiałów, przenosi się tu jeden do jednego: termin ma jedną kanoniczną formę i ta sama forma idzie przez wszystkie dokumenty. Najgorszy wariant to trzy nazwy tego samego pola w trzech przestrzeniach - „Kryteria akceptacji", „Acceptance Criteria" i „AC" - bo wtedy żaden filtr ani raport nie obejmie całości.

Drugi wybór do podjęcia świadomie: czy skrót „AC" w ogóle wchodzi do obiegu. W rozmowie jest wygodny. W dokumencie, który czyta ktoś spoza zespołu, bywa zagadką - zwłaszcza że w tym samym zdaniu potrafią stać obok siebie DoD, DoR i UAT.

Które angielskie nazwy z sąsiedztwa znaczą co innego?

Większość poniższych terminów krąży wokół pytania „czy to jest gotowe", ale każdy odpowiada na nie na innym poziomie. Dwa ostatnie wiersze wchodzą do tabeli z innego powodu: mylą się z kryteriami przez sąsiedztwo, nie przez znaczenie.

Termin angielskiPo polskuCzego dotyczy
acceptance criteriakryteria akceptacjiwarunki dla JEDNEJ historyjki albo jednego wymagania
definition of donedefinicja ukończeniawspólny standard dla KAŻDEJ historyjki w zespole
definition of readydefinicja gotowościwarunki wejścia, zanim historyjka trafi do sprintu
UATtesty akceptacyjne użytkownikamoment odbioru przez biznes, już po zbudowaniu
test casesprzypadki testowekroki testera z danymi wejściowymi i oczekiwanym wynikiem
BDDrozwój sterowany zachowaniempodejście, z którego przyszła składnia Given-When-Then
INVEST-zestaw cech dobrej historyjki; nie dotyczy kryteriów

Mylone bywają przede wszystkim dwa pierwsze wiersze. Kryteria akceptacji są inne dla każdej historyjki, bo opisują konkretną sprawę. Definicja ukończenia jest jedna dla wszystkich i mówi o standardzie pracy zespołu, na przykład o tym, że kod przeszedł przegląd i że dokumentacja jest zaktualizowana. Rozdzielenie obu, razem z przykładami, opisuje wpis o Definition of Done i Definition of Ready.

Zostaje jeszcze pytanie, skąd te kryteria w ogóle się biorą. Lekcja 04 minikursu o historyjkach nazywa je trzecim C z układu Card, Conversation, Confirmation - kartą, rozmową i potwierdzeniem. Kryteria to Confirmation, czyli pisemny ślad tego, na co zespół się umówił. Angielska nazwa nie zmienia tu nic: dokument spisany w samotności przy biurku nie staje się kryteriami akceptacji przez to, że został nazwany „acceptance criteria".

Kiedy pisać kryteria po angielsku, a kiedy po polsku?

Decyduje to, kto będzie czytał artefakt i kto ma na nim postawić podpis.

Po angielsku pisz, gdy w łańcuchu czytających jest ktoś, kto nie mówi po polsku - deweloper z innego kraju, tester z zespołu dostawcy, klient zagraniczny odbierający wdrożenie. Wtedy angielski jest językiem umowy, a nie ozdobą.

Po polsku pisz, gdy odbiór robi polski biznes. Kryteria są podstawą zatwierdzenia i podstawą testów odbiorczych, a osoba z działu operacyjnego ma je przejść punkt po punkcie i powiedzieć „to się zgadza". Zmuszanie jej do czytania scenariuszy po angielsku to dokładanie ryzyka tam, gdzie kryteria miały je zdejmować.

Jedna zasada obowiązuje w obu wariantach: jeden język w jednym artefakcie. Scenariusz, w którym „Given" jest po angielsku, treść po polsku, a nazwy statusów znowu po angielsku, czyta się najgorzej ze wszystkich możliwych wersji - i najłatwiej w nim przeoczyć, że dwa kryteria mówią to samo. Całą ścieżkę: jak wymagania udokumentować, zweryfikować, zwalidować i zatwierdzić według BABOK Guide, przerabiamy w programie kursu wprowadzającego do analizy biznesowej.

Jeżeli sprawdzasz właśnie, czy umiesz pisać takie kryteria samodzielnie, załóż darmowe konto - w wersji bezpłatnej dostajesz pierwszą lekcję każdego kursu, trzy podejścia do testów w miesiącu i plan na 30 dni.

Rozwijaj się z Analify

Nowe pojęcia, artykuły i materiały - prosto na email. Bez spamu.

Dołącz do społeczności analityków biznesowych - szkolenia wideo, prelekcje na żywo i wsparcie ekspertów

Sprawdź Analify