Пользовательская история, как элемент в вашем отставании, является заполнителем для разговора. В этом разговоре, владелец продукта и команда разработчиков достигнут понимания желаемого результата.
Критерии приема сообщают команде разработчитов, как должен вести себя код. Избегайте написания **«Как»** в пользовательской истории; придерживайтесь **«Что»** . Если команда следит за развитием тестирования (TDD), она может служить основой для автоматических тестов. Критерии принятия будут началом плана тестирования для команды QA.
Критерии приемлемости можно рассматривать как инструмент защиты Команды доставки. Когда Группа доставки обязуется фиксировать множество историй в планировании Спринта, они фиксируют также набор критериев приемлемости. Это помогает избежать ползучести.
Рассмотрим следующую ситуацию: при принятии пользовательской истории владелец продукта предлагает добавить то, что не входит в сферу истории пользователя. В этом случае команда доставки может отклонить этот запрос (как бы мала она ни была) и попросить владельца продукта создать новую историю пользователя, о которой можно позаботиться в другом Sprint.
#### Дополнительная информация:
Nomad8 предоставляет [FAQ по критериям приема](https://nomad8.com/acceptance_criteria/)