Что такое юзер стори

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

Для аналитика это вопрос про умение формулировать потребность от пользователя, а не от системы. Смотрят, понимаете ли вы, что история это не документ на подпись, а компактное обещание разговора, у которого обязаны быть ценность и проверяемые критерии приёмки.

Как отвечать

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

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

Сильный ответ добавляет границу применимости. Логика с десятками ветвлений, интеграционные контракты и требования регулятора живут в отдельных документах, а история на них ссылается, иначе карточка распухает и перестаёт быть обсуждаемой.

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

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

Часть «чтобы» повторяет часть «я хочу» другими словами. Шаблон формально соблюдён, но зачем это пользователю, из текста непонятно, и приоритезировать такую историю не по чему.

Сдают историю без критериев приёмки. Границы дальше определяет тот, кто первым взял задачу, тестировщик проверяет своё понимание, а на демонстрации выясняется, что сделали не то. Критерии пишутся до начала работы, а не после.