Как описывать юз кейсы и юзер стори для разработчиков

Что проверяют

Знаете ли вы разницу между двумя форматами и умеете ли выбрать нужный под задачу, а не только помните шаблон «Как роль, я хочу действие, чтобы ценность». Следом обычно просят показать критерии приёмки и спрашивают, как вы убеждаетесь, что разработчик понял требование так же, как вы.

Как отвечать

Разведите форматы по назначению:

• user story: короткая единица ценности для бэклога, повод для разговора, а не спецификация. Например: «Как соискатель, я хочу сохранить вакансию, чтобы вернуться к ней позже». Качество проверяют по критериям INVEST;
• критерии приёмки: без них история не готова к разработке. Удобен формат Given/When/Then из Gherkin, он сразу превращается в тест-кейсы;
• use case: полное описание взаимодействия актора с системой ради цели. Предусловия, триггер, основной сценарий по шагам, альтернативные и исключительные потоки, постусловия. Нужен там, где важна каждая ветка: сложная логика, интеграции, регуляторные требования.;
• что приложить для разработчика: макеты в Figma, контракт API в OpenAPI, модель данных, диаграмму последовательности для интеграций, BPMN для процесса, нефункциональные требования;
• Definition of Ready: договорённость с командой, что история без критериев приёмки в спринт не берётся.

Хорошо показать связку: из одного use case вырастает несколько историй. Основной сценарий оформления заказа одна история, оплата частями другая, отказ банка третья. Дальше опирайтесь на свой опыт: как вы проводили груминг или встречу «трёх амиго» с разработчиком и тестировщиком. Если опыта мало, скажите, как проверили бы понимание: попросить разработчика пересказать требование своими словами.

Где спотыкаются

Пишут историю от лица системы или команды: «Как бэкенд, я хочу новую таблицу». Это техническая задача без пользовательской ценности, и оформлять её нужно иначе.

Считают, что юзер стори заменяет спецификацию. Для интеграции или сложного расчёта одной фразы и трёх критериев мало, нужны use case, контракт и примеры данных.

Пишут критерии, которые нельзя проверить: «удобно», «быстро», «корректно». Тестировщик не сможет принять такую историю, а разработчик сделает на своё усмотрение.