Это условия для User Story, чтобы ее можно было считать выполненной. Это определенный стандарт результата, которому должно соответствовать предлагаемое решение или функция.

Критерии приемки делают более понятной ту User Story, над которой ведется работа. За счет этого снижается вероятность переделок и исправлений в работе, поскольку она сразу выполняется с нужным качеством.

Пишите Acceptance Criteria с точки зрения пользователя, как если бы у него были конкретные пожелания к функциональности. В этом смысле написание похоже на описание User Story — простое и понятное каждому, отражающее потребность пользователя.

Acceptance Criteria («критерии приема», AC) — это набор условий, которым должна удовлетворять User Story, чтобы ее считали выполненной.

Он предоставляет подробный охват User Story и того, что нужно, чтобы ваша команда могла понять, какие задачи перед ней стоят.

Таким образом, каждый раз, когда вы создаете новую функцию, вы можете быть уверены, что эта функция соответствует стандарту, которого заслуживают ваши пользователи.

Но прежде чем вы с энтузиазмом объявите набор функциональных критериев, которые должны быть соблюдены для User Story, подумайте о том, как другие переменные могут также повлиять на качество вашей функции, и включите их в ваш Acceptance Criteria.

Acceptance Criteria может включать в себя такие детали, как:

• Пользовательский опыт
• Влияние текущей User Story на существующие функции
• Ключевая метрика производительности (например, скорость)
• Что User Story должна делать

Итак, основываясь на функции, которую вы создаете, и ее сложности, вам с вашей командой нужно выяснить — какой минимальный набор функций должен быть разработан.

Если речь идет о сложной или самой основной функции вашего продукта, вы должны написать как можно больше и подробных Acceptance Criteria, чтобы помочь вашей команде избежать путаницы.

1. Acceptance Criteria должно быть написано с точки зрения пользователя.

Acceptance Criteria — это способ взглянуть на проблему с точки зрения клиента. Они должны быть написаны в контексте реального опыта пользователя.

В конце концов, вы создаете свой продукт для своих пользователей, верно?

1. Критерии должны быть четкими, краткими, понятными.

Acceptance Criteria не следует путать с документацией.

Важно, чтобы ваши критерии были максимально простыми и понятными. Их будет читать и на них будет ориентироваться ваша команда. Каждый должен понимать ваш Acceptance Criteria.

Ваши критерии бесполезны, если ваши разработчики не могут их понять.

Если вы не уверены в том, что что–то понятно, найдите время, чтобы спросить и внести изменения, пока все не станет ясно.

1. Acceptance Criteria не о том «как». Это о том «что».

Как и User Story, Acceptance Criteria не являются задачами.

Они представляют собой скорее технологию общения о User Story, инструмент обсуждения.

1. Acceptance Criteria может быть повторением User Story с точки зрения пользователя.

Это возможно, только если история пользователя не слишком сложна.

Вот пример того, о чём речь.

Допустим, User Story звучит так: «Как финансовый сотрудник, я хочу принимать счета, чтобы иметь возможность отслеживать все мои финансовые движения».

Acceptance Criteria звучит просто: «Когда я выполняю действие «принять», счёт принимается (и это проверяется путем проверки записей для счётов)».

Чтобы упростить жизнь, вот простой шаблон, который вы можете использовать для написания Acceptance Criteria:

Учитывая [контекст], когда [выполняется конкретное действие], тогда [должно произойти следствие]

Разберем этот шаблон на примере пользовательской истории:

«Как писатель, я хочу получать уведомления, когда другие добавляют комментарии, чтобы я был в курсе».

Вот три примера Acceptance Criteria для вышеупомянутой пользовательской истории:

• Поскольку у меня не открыто приложение, когда мой телефон заблокирован, я должен получить уведомление в виде баннера.
• Поскольку у меня есть открытое приложение, когда я пишу в документе, значок колокольчика должен обновиться, чтобы показать непрочитанные уведомления с количеством.
• Если пользователь был упомянут в комментарии с помощью @ упоминания, когда упомянутый пользователь читает комментарии, то в той же цепочке комментариев должно появиться флэш сообщение о новом комментарии.

Мы рекомендуем пользователям добавлять все Acceptance Criteria в качестве описания к пользовательской истории. Тогда, когда члены вашей команды возьмут User Story, они получат полную картину того, что требуется для завершения.

Практически каждый в кросс–функциональной команде может написать Acceptance Criteria для пользовательских историй.

В большинстве случаев именно Acceptance Criteria пишет Product Owner или Project Manager, потому что важно писать его с точки зрения клиента. И кто лучше понимать клиента, чем они, отвечающие за ценность продукта и взаимодействие с клиентами?

Нередко пишут Acceptance Criteria для пользовательской истории, готовя отставание незадолго до груминга бэклога или до планирования спринта для обсуждения приоритетов.

Однако многие люди предпочитают обсуждать приоритеты перед тем, как писать Acceptance Criteria, поскольку приоритеты всегда могут меняться в зависимости от новых знаний. И, написав Acceptance Criteria, как только были расставлены приоритеты, команда добивается уменьшения этой неопределенности и не тратит время на вещи, которые не являются приоритетными.

Это, однако, не правильный подход.

Хотя вы тратите время на приоритетный список пользовательских историй, отсутствие Acceptance Criteria перед определением приоритетов может помешать прогрессу приоритизации.

Так что мы рекомендуем писать Acceptance Criteria до приоритизации.

В конце концов, вам нужна вся доступная информация для эффективной расстановки приоритетов. Поэтому это действие следуете делать последним.