🌟 Тренинги для компаний
group 7 equalizer 4

Acceptance Criteria — критерии приёма и завершения работы над User Story

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

В этой статье мы разберем, что такое Acceptance Criteria, как этот критерий связан с пользовательской историей, как нужно писать этот критерий.

Что такое Acceptance Criteria?

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

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

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

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

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

  • Пользовательский опыт

  • Влияние текущей User Story на существующие функции

  • Ключевая метрика производительности (например, скорость)

  • Что User Story должна делать

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

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

Acceptance Criteria

Как написать Acceptance Criteria для User Story?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаблон Acceptance Criteria

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

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

Образцы Acceptance Criteria

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

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

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

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

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

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

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

Кто пишет Acceptance Criteria?

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

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

Когда следует писать Acceptance Criteria?

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

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

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

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

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

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

⚡ Ответим вам по электронной почте в течение 30 минут
По телефону — мгновенно, ежедневно с 9:00 до 20:00
Коломенский Андрей из LeadStartup
Андрей Коломенский
— Мы в LeadStartup за прошлый год завершили 16 кейсов по росту прибыли и выводу новых продуктов на рынок.
Треть — убыточны, лучший кейс: 99% годового плана за полтора месяца. География рынков: Россия, США и Китай.
Если вы руководитель и отвечаете за деньги — давайте общаться. Дадим конкретику, как можно вырастить прибыль вашего продукта и релевантные кейсы.
  • Мы имеем десятки успешных кейсов запуска новых продуктов в рамках крупных компаний — финтех–стартапы, маркетплейсы, классифайды, включая международные проекты на рынках США и Китая.
  • Мы — практики. За нашими плечами миллионы слитых рублей на маркетинг собственных продуктов, которые сейчас приносят прибыль. Все знания добыты своими деньгами и тяжелой работой.
  • С вами будут работать предприниматели, которых интересуют только реальные результаты по возврату вложенных инвестиций, прибыли и EBITDA.
  • Более 16 лет реального коммерческого опыта в разработке IT–продуктов. Насмотренность по сотням проектов. Сотрудничаем с Baymard Institute.
⚡ Ответим по электронной почте в течение 30 минут
По телефону — мгновенно, ежедневно с 9:00 до 20:00