Что обычно пишут в юзер стори кроме описания
Что проверяют
Умеете ли вы доводить историю до состояния, в котором её можно взять в спринт без дополнительных расспросов. Формулировка «как роль, я хочу действие, чтобы получить ценность» это только карточка, работа начинается дальше.
Как отвечать
Кроме описания в истории обычно есть:
- критерии приёмки: проверяемые условия готовности, чаще всего сценарии в формате «дано, когда, тогда» или чеклист. По ним тестировщик пишет проверки, а команда понимает границу задачи;
- ценность и контекст: зачем это нужно, какую метрику двигаем, что будет, если не делать;
- ограничения и нефункциональные требования: время ответа, нагрузка, права доступа, поддерживаемые устройства, требования к данным;
- краевые случаи и ошибки: пустое состояние, недоступность смежного сервиса, повторная отправка;
- зависимости: чужие сервисы, соседние команды, порядок относительно других историй;
- ссылки: макеты, контракт API, список событий аналитики;
- оценка, приоритет, автор и заказчик.
Полезно сослаться на INVEST как на способ проверить историю: независима, обсуждаема, ценна, оценима, невелика, проверяема.
Где спотыкаются
Пишут критерии приёмки пересказом описания: «форма работает корректно». Проверить это нельзя. Критерий формулируется через наблюдаемый результат: что ввели, что произошло, что увидел пользователь и что записалось.
Второе: подменяют потребность решением. История «добавить кнопку в правый верхний угол» лишает команду права предложить более дешёвый способ, а проверять в ней нечего, кроме факта наличия кнопки.
Третье: приносят историю размером с эпик. Признаки видны сразу: критериев больше десятка, затронуты три подсистемы, оценка не сходится. Резать такую историю нужно по сценариям, а не по слоям: вариант «отдельно бэкенд, отдельно интерфейс» даёт куски, которые сами по себе пользователю ничего не дают.