Acceptance Criteria
Acceptance Criteria — обязательное приложение к каждой User Story. Это чек-лист, по которому история проверяется на готовность.
Хорошие AC:
- Конкретны и проверяемы (можно сказать «выполнено» или «нет»)
- Описывают поведение, а не реализацию
- Покрывают и happy path, и edge cases
- Согласованы с PO до начала работы
Популярный формат — Given / When / Then (BDD-стиль):
- Given [контекст]
- When [действие]
- Then [результат]
Пример: «Given пользователь авторизован, When он нажимает «Экспорт в CSV», Then скачивается файл с заголовками строк».
Когда применять и когда нет
Применять
- Работаете в Scrum или Kanban с историями
- Нужна чёткая граница «история сделана/нет»
- QA должен иметь критерии для приёмки
Не применять
- Чисто исследовательские задачи (Spike) — там AC может не быть, есть Definition of Done «составлен отчёт»
Примеры применения
История: «Как менеджер, я хочу экспортировать отчёт в CSV, чтобы поделиться им с финансами».
AC:
• На странице отчёта есть кнопка «Экспорт в CSV».
• При клике скачивается файл report-YYYY-MM-DD.csv.
• Файл содержит все колонки таблицы.
• Кодировка — UTF-8 с BOM (для Excel).
• При пустом отчёте кнопка disabled.
Часто задаваемые вопросы
AC — конкретные функциональные критерии для одной истории. DoD — общий стандарт качества для всех задач команды (тесты, ревью, документация).
Чаще всего — Product Owner. Команда уточняет и дополняет на Refinement. QA может предложить дополнительные edge cases.
Обычно 3–7. Если меньше 2 — история слишком тривиальна или плохо описана. Больше 10 — стоит разбить на несколько историй.