User stories и acceptance criteria

User stories и acceptance criteria в delivery: что важно знать

User stories и acceptance criteria — это рабочие инструменты для описания требований к фичам и задачам. В деливери они служат основой для планирования, проверки, приёмки и оценки качества поставки. Правильное оформление сокращает баги, помогает разработчикам и тестировщикам понимать ожидания и ускоряет релизы. Здесь только практика и конкретика: как оформить, что контролировать, где чаще ошибаются.

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

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

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

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

Хорошие acceptance criteria — это минимальный контракт доверия между бизнесом и командой. Если критерии выполнили — задачу можно принимать.

— Роман Савин, эксперт по agile (по мотивам курса ru.hexlet.io)

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

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

Acceptance criteria:

Пользователь может сменить пароль на странице профиля.
Новый и старый пароли обязательны к заполнению.
Ошибка при несоответствии старого пароля.
После смены пароля пользователь получает 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 покрывают все варианты поведения, включая негативные сценарии
Без оценочных суждений вроде «быстро» или «красиво»

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

— Майк Кон, автор книги User Stories Applied (source)

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

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

Истории без явного пользователя или цели
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