🔥 100+ СТАРТАП–ИНСТРУМЕНТОВ — ПОЛУЧИТЕ БЕСПЛАТНО
group 21 equalizer 4

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

ПОЛУЧИТЕ БЕСПЛАТНО 100+ СТАРТАП–ИНСТРУМЕНТОВ
🔥 Доступ к Google–диску, со всеми материалами компании LeadStartup
  • Таблица расчета юнит–экономики стартапа и PnL компаний.
  • Постеры ведущих подходов к управлению — Agile, Scrum, LeanKanban.
  • Постеры методов запуска стартапов — Lean Startup и Customer Development.
  • ТОП 20 основополагающих книг по менеджменту и стартапам.
  • 100+ эссе по управлению разработкой новых продуктов.
  • Карта компетенций руководителя стартапа и digital–продуктов.
  • ... и еще сотня полезного материала и инструментов. Бесплатно.

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

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

Доступно в Google Play и App Store
🔥 Онлайн–обучение созданию стартапов
Вы приобретете 14 управленческих компетенций, востребованных как для работы в крупных компаниях, так и при запуске стартапов.
  • Обучаем с нуля до позиции Chief Product Owner — вы станете тем, кто отвечает за прибыльность новых бизнес–направлений.
  • Обучаем с нуля до позиций Scrum Master и Agile Coach — руководителей нового типа.
  • Обучаем компетенциям Chief Executive Officer — вы поймете как вывести на рынок собственный продукт, без бюджета на запуск.
Узнайте больше

Что такое Acceptance Criteria?

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

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

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

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

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

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

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

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

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

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

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

Acceptance Criteria

🔥 Освойте методологию запуска стартапов из кремниевой долины — Lean Startup и Customer Development, с сертификацией.
Lean Startup Customer Development Юнит–экономика Jobs To Be Done AARRR MVP & RAT Диффузия инноваций Канвас бизнес–модели Разработка ценностных предложений Scrum
Узнайте больше

Как написать 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 звучит просто: «Когда я выполняю действие “принять”, счёт принимается (и это проверяется путем проверки записей для счётов)» .

⭐ Корпоративные тренинги от 142 600 рублей

Шаблон 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 до приоритизации.

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

Agile Scrum тренинг
⭐️ — Качественное корпоративное обучение Agile–практикам управления
от 142 600 рублей Россия Европа Китай
Lean Startup Customer Development Юнит–экономика Jobs To Be Done MVP за 2 месяца Agile Scrum Design Thinking OKR Growth Hacking Lean Product Management LeanKanban
⚡ Ответим вам по электронной почте в течение 30 минут
По телефону — мгновенно, ежедневно с 9:00 до 20:00
— Обожаем работать на результат с теми, кто отвечает за EBITDA, ROI, CLTV, прирост доли рынка и продажи.
⭐️
Познакомимся, поделимся подходом, кейсами и ответим на вопросы о результативности и возврате инвестиций
ВТБ
HomeCredit
TUI
Лаборатория Знаний
Cauri Payment Systems
Play!
Musicabinet
Мандариновая Лиса
DETTKI
MIRRAR
Lanit интеграция
LaNature
NAMM
MMS
120 Секунд
12 Storeez
Альфа Банк
AMS
BAT
CTF
DTK
ICL
IKEA
KT.Team
KT.Team
MTS
OTK
Platron
Platron
Ростелеком
Toyota Bank
VSB
VSLH
X5
Сбербанк
Universal University
Agile Coach Agile Coach Аджайл-коуч Скрам-мастер
Обучение менеджменту в Agile
Agile Coach & Agile Coach
Корпоративный тренинг
Agile / Scrum / Kanban
Certified Agile Professional
Lean Product Management Тренинг для компаний Программа обучения Запуск и внедрение Курс обучения Customer Development
Вывод на рынок нового продукта за 3 месяца
Lean Customer Development
Дизайн Мышление Корпоративный тренинг До 24 человек Курс обучения
Программа обучения Дизайн Мышление
Дизайн Мышление
Для руководителей и менеджеров Корпоративный тренинг Воркшоп
Командообразующий воркшоп с обучением основам Канбан–метода
GetKanban Workshop
Growth Hacking Корпоративный тренинг До 24 человек Курс обучения
Петли роста и системное мышление
Growth Hacking
JTBD Корпоративный тренинг До 24 человек Курс обучения
Вы научитесь понимать, почему клиенты покупают и используют ваши продукты
Jobs To Be Done
Advanced Kanban–master Корпоративный тренинг До 24 человек Курс обучения
Программа обучения Kanban
Kanban System Design
Product Owner Владельц продукта Продакт Менеджмент Scrum Product Owner
Обучение роли Владельца Продукта
Lean Product Owner
Обучение бережливому запуску новых компаний и подразделений
Lean Startup Professional
Objectives & Key Results Корпоративный тренинг Курс обучения
Обучение OKR
Целеполагание по OKR
Professional Scrum Master Корпоративный тренинг До 24 человек Курс обучения
Lego4Scrum
Scrum Foundation Workshop
Scrum Master Аджайл-коуч Скрам-мастер
Обучение менеджменту в Scrum
Scrum Master
Кастдев User Research
Глубинные интервью с клиентами
Проведение глубинных интервью
Проведение ретроспективы
Проведение ретроспективы
Трекинг / консалтинг продуктовых и проектных команд
Трекинг