User stories и acceptance criteria

User story — повод для разговора о ценности и поведении, а не способ уместить требования в одно предложение. Критерии приёмки должны снять неоднозначность на важных ветках сценария, включая ошибки и права доступа, но не превращаться в пошаговое техническое решение.

Что такое user stories и acceptance criteria

Определения и задачи

User story — это короткое описание потребности пользователя или кейса. Обычно структура такая: Как [тип пользователя], я хочу [действие], чтобы [цель]. Acceptance criteria — это чёткие условия, когда история считается выполненной. Они конкретизируют требования и служат чек-листом для проверки.

User stories отвечают на вопрос кто и что хочет, acceptance criteria — когда этот запрос реализован правильно.

Примеры в работе

Пример user story: Как зарегистрированный пользователь, я хочу изменить свой пароль, чтобы повысить безопасность своей учетной записи.

Acceptance criteria:

1. Пользователь может сменить пароль на странице профиля.
2. Новый и старый пароли обязательны к заполнению.
3. Ошибка при несоответствии старого пароля.
4. После смены пароля пользователь получает email-уведомление.

Зачем нужны user stories в delivery

Связь с процессами поставки

User stories — основной элемент для планирования и разбиения работы на задачах. Если история описана конкретно и коротко, команда оценит объём работы, не упустит детали и не запутается в требованиях.

Acceptance criteria превращают пожелания в измеримые результаты. Это критерии приёмки — по ним проверяют, что поставили именно то, что нужно, и ничего не упустили.

Как это помогает

В планировании:

• Истории удобно обсуждать с командой — всем ясно, как выглядит успех
• Быстрее выявляются сложные или неясные моменты на этапе предельно дешёвом — до внедрения

В тестировании:

• Acceptance criteria — база для тест кейсов
• Автоматизировать проверку через BDD-сценарии легче, когда критерии уже чётко сформулированы

В приёмке:

• Продукт-менеджеру не нужно додумывать: checklist уже готов
• Нет разночтений между бизнесом и командой

Пример: Если описать историю для кнопки обратной связи только как «Сделать кнопку обратной связи», дизайн и поведение могут отличаться от ожиданий. Если же добавить чёткие acceptance criteria — вид, место, реакцию на клик, то неожиданных вопросов не возникнет.

Как писать хорошие user stories и acceptance criteria

Лучшие практики оформления

User stories: коротко, по структуре, без лишних деталей. Не скатывайся в технические задачи вроде «Сделать REST API». Думай с позиции пользователя.

Acceptance criteria: однозначные, проверяемые, не пересекаясь друг с другом.

Рекомендации:

• Одна история — одна пользовательская задача
• Acceptance criteria покрывают все варианты поведения, включая негативные сценарии
• Без оценочных суждений вроде «быстро» или «красиво»

Антипаттерны и ошибки

Частые ошибки:

• Истории без явного пользователя или цели
• Acceptance criteria не покрывают крайние случаи
• Критерии противоречат друг другу или дублируются
• В acceptance criteria только happy path — не предусмотрены ошибки

Пример: На проекте запланировали фичу «Поделиться статьей». Acceptance criteria не учитывали, что ссылка может быть приватной. В итоге пользователи расшаривали приватные материалы публично. Если бы критериям уделили больше внимания — избежали бы инцидента.

Валидация и приёмка: процессы, роли, метрики

Кто отвечает и что проверять

Чаще всего за формулировку user stories и acceptance criteria отвечает продукт-менеджер или владелец продукта. К обсуждению подключают разработчиков, тестировщиков, дизайнеров — для проверки реализуемости и полноты.

На этапе delivery проводят:

• Груминг (разбор требований и уточнение критериев)
• Демонстрацию (демо) выполненной задачи по acceptance criteria
• Приёмку фичи по чек-листу критериев

Метрики и качество

Точные цифры по времени на приемку и исправление багов зависят от рынка и компании. На практике смотрят:

• % user stories с формализованными acceptance criteria (доля формализованных требований)
• Время от завершения задачи до приёмки (cycle time)
• Количество дефектов, не словленных на этапе описания

Как использовать user stories и acceptance criteria в инструментах

В jira, backlog, bdd

В jira user stories и acceptance criteria обычно выносят в описание задачи. Acceptance criteria можно держать отдельным списком checklist — это удобно для тестирования и автоматизации. Если ваша команда использует BDD (Behavior Driven Development), критерии описывают через формат Given–When–Then.

Пример для BDD: Given пользователь на странице профиля
When вводится верный старый и новый пароль
Then появляется сообщение об успешной смене, отправляется email

Как не терять критерии при изменениях

В практике часто забывают обновлять acceptance criteria при изменении требований. Решение: держать критерии в едином источнике правды (например, в jira или в общем doc), следить за их актуальностью при каждом редактировании истории.

FAQ: частые вопросы

Чем user story отличается от задачи?
User story описывает потребность пользователя, задача — конкретную работу, которую надо выполнить для реализации истории.

Кто формулирует acceptance criteria?
Обычно отвечает продукт-менеджер. Но уточнять критерии должны вместе с разработчиками и тестировщиками.

Можно ли менять acceptance criteria в процессе спринта?
Лучше избегать, иначе планирование теряет смысл. Если критерии меняют — обсуждай это с командой.

Что делать, если acceptance criteria пропущены?
Возвращайся к истории, добавляй критерии до старта разработки. В противном случае недопонимания обеспечены.

Обязательны ли негативные сценарии в acceptance criteria?
Желательно, иначе ошибки и тупиковые ситуации пройдут мимо.

Где почитать подробнее?
Atlassian guide
Mike Cohn: User Stories