User stories и acceptance criteria для системного аналитика

Зачем спрашивают

User stories — формат описания требований в Agile-командах. Системный аналитик пишет их каждый день. На собесе дадут кейс: «опишите user story на новую фичу — оформление возврата товара». Ожидают правильный формат, разумные acceptance criteria, понимание INVEST-принципов.

Главная боль без понимания темы — analyst пишет требования простыней без структуры. Команда не понимает, что закончено: фронт думает «по AC ок», бэк говорит «не оговорено», тестировщик не знает, что проверить. Бесконечные созвоны, фича буксует.

Story + AC — стандартный артефакт ТЗ в Scrum/Kanban. Без понимания формата SA не пройдёт собес ни в продуктовой команде, ни в банке.

Формат user story

Как <роль>,
я хочу <действие>,
чтобы <выгода / цель>.

Пример:

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

Три части:

1. Роль — кто пользователь. Конкретная роль, не «пользователь системы».
2. Действие — что делает в системе.
3. Выгода — зачем, какая боль закрывается. Это часто пропускают, и зря.

«Зачем» (выгода) — самая важная часть. Без неё story превращается в техническое требование без бизнес-смысла. Команда не сможет предложить альтернативу решения, потому что не знает цель.

Story != фича. Фича может состоять из 5–10 stories. Story должна влезать в один спринт (1–5 дней работы команды).

INVEST

Чек-лист хорошей story (Bill Wake):

• Independent — независима от других stories (можно разработать в любом порядке)
• Negotiable — детали обсуждаемы, не «жёсткое ТЗ»
• Valuable — даёт ценность пользователю / бизнесу
• Estimable — команда может оценить трудоёмкость
• Small — влезает в один спринт
• Testable — есть критерии приёмки, можно проверить

Independent — самый сложный. Если story требует, чтобы сначала была сделана другая — это не independent. Решения: либо объединить, либо переформулировать (часть value через mock).

Negotiable — story не «прибита гвоздями». В обсуждении на refinement команда может предложить упрощение или альтернативу.

Estimable — если команда не понимает, как оценить, story слишком большая или непонятная. Дробить или уточнять.

Small — большие stories (epic) разбивать. Эвристика: больше 5 дней работы — дробить.

Acceptance criteria

AC — список условий, которые должны выполниться, чтобы story считалась завершённой. Они нужны:

• Команде: что делать
• Тестировщику: что проверять
• Аналитику: ясно сформулировать ожидания

Виды AC:

1. Чек-лист (простой формат)

   • Кнопка «Возврат» отображается на странице заказа со статусом «доставлен»
   • При клике открывается модал с выбором товаров
   • После подтверждения создаётся заявка на возврат, появляется в ЛК

2. Given/When/Then (BDD-формат, см. ниже)

3. Свободный текст — для нефункциональных требований (performance, безопасность)

Хорошие AC:

• Конкретны и проверяемы
• Покрывают happy path и edge cases
• Не дублируют story
• Описывают что, не как (без implementation details)

Плохие AC:

• «Должно работать корректно»
• «Должно быть удобно»
• «По стандартам компании»

Given/When/Then

Формат BDD (Behavior-Driven Development). Каждый сценарий:

Given <предусловие>
When <действие>
Then <ожидаемый результат>
And <дополнительные условия>

Пример:

Сценарий: успешное создание возврата

Given у пользователя есть заказ в статусе «доставлен»
And с момента доставки прошло меньше 14 дней
When пользователь нажимает «Создать возврат» и выбирает один товар
And подтверждает запрос
Then заявка на возврат создаётся со статусом «новая»
And в личном кабинете в разделе «Возвраты» появляется новая карточка
And пользователь получает email с подтверждением

Ещё сценарии:

Сценарий: отказ при превышении срока возврата

Given у пользователя есть заказ в статусе «доставлен»
And с момента доставки прошло больше 14 дней
When пользователь открывает страницу заказа
Then кнопка «Создать возврат» не отображается
And на странице есть текст «Срок возврата истёк»

Преимущества Given/When/Then:

• Однозначность
• Лёгко переводится в автотест
• Тестировщик не угадывает поведение

Минусы: многословно. Для простых stories чек-лист может быть достаточен.

DoR и DoD

Definition of Ready (DoR) — критерии, при которых story готова в работу:

• User story в формате роль/действие/цель
• AC написаны
• Зависимости (другие команды, API) выявлены
• Дизайн (если нужен) приложен
• Estimate проставлен
• Команда понимает, что делать

Definition of Done (DoD) — критерии завершения story:

• Код написан и прошёл review
• Unit/integration тесты написаны и проходят
• AC выполнены
• Документация обновлена (API doc, конфлюенс)
• Развёрнуто на staging
• Тестировщик подтвердил
• Deployable (готово к prod)

DoR/DoD — соглашения команды, не догма. Должны быть согласованы и видимы (Confluence, физическая доска).

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

Story без «зачем». «Как админ, я хочу кнопку экспорта в CSV». Зачем? Без обоснования команда не может предложить альтернативу или приоритизировать.

Технические story. «Рефакторинг сервиса auth». Это не user story — это таск. Рефакторинг можно обернуть в story «как разработчик, я хочу читаемый код auth, чтобы быстрее добавлять фичи», но честнее — отдельный backlog для technical debt.

AC слишком общие. «Должно быть быстро», «удобно». Бесполезно. AC = конкретные проверяемые условия.

AC = implementation. «Запрос идёт в сервис auth через JWT». Это implementation, не AC. AC — поведение, не код.

Зависимости в story. «Story B зависит от A, A зависит от C» — нарушает Independent. Дробить, объединять или строить feature toggle.

Big stories. «Реализация всей системы возвратов» — это epic, не story. Epic дробится на stories по этапам.

DoD «по умолчанию». Каждая команда должна иметь свой DoD. «Как раньше» при росте проекта — путь к багам в проде.

Связанные темы

• Подготовка к собесу системного аналитика
• Сoбеседование системного аналитика
• REST API на собесе SA
• Как написать PRD: шаблон с примером
• Как написать аналитический отчёт

FAQ

Чем user story отличается от use case?

User story — короткое описание потребности с фокусом на ценность («роль/действие/цель»). Use case — детальный сценарий взаимодействия с системой (актёры, основной/альтернативный/исключительный потоки). User story — для Agile-планирования, use case — для подробного проектирования.

Должна ли AC покрывать negative paths?

Да, желательно. Если есть критичные edge cases (отказы, лимиты, ошибки) — отдельные AC. Не покрывать all imaginable, но покрыть бизнес-критичные.

Как делить epic на stories?

Vertical slicing: каждая story — кусок full-stack функциональности (UI + API + БД), приносящий value. Не horizontal (отдельная story «бэк», «фронт», «БД» — это таски, не stories).

Можно ли иметь story без AC?

Технически да, в начале планирования. Но в DoR обычно требование AC. Без AC story нельзя оценить и тестировать.

User story в Confluence или Jira?

Чаще в Jira (как тип Issue). Большие epic с детальным дизайном — Confluence-страница, привязанная к Jira-эпику.

Это официальная информация?

Нет. Статья основана на работах Mike Cohn (User Stories Applied), Bill Wake (INVEST), Dan North (BDD) и общей agile-практике.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.