Как проверить качество User Story

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

Умеете ли вы оценить историю до того, как она ушла в разработку, а не после возврата с тестирования. Интервьюер ждёт не расшифровку INVEST, а способ проверки на практике. Следом обычно просят разобрать плохую историю или разбить слишком крупную.

Как отвечать

Проверку удобно вести по слоям:

• формулировка: «Как <роль>, я хочу <действие>, чтобы <ценность>». Роль это реальный пользователь, а не «система» или «разработчик», часть «чтобы» объясняет выгоду, а не повторяет действие;
• INVEST как вопросы: можно ли сделать историю без соседней, описывает ли она проблему, а не готовое решение, может ли команда её оценить, влезает ли в спринт, понятно ли, как проверить результат;
• критерии приёмки: конкретные и проверяемые, удобно в формате Given/When/Then. «Список грузится быстро» не критерий, «первая страница из 20 заказов открывается быстрее 2 секунд» уже да. Нужны и негативные сценарии: пустой список, нет прав, ошибка сервиса;
• 3C: карточка, разговор, подтверждение. История это повод обсудить, поэтому без разговора с командой её качество не проверить;
• Definition of Ready: командное соглашение, при каком условии история берётся в спринт: есть макет, критерии, известны зависимости.

Главный практический инструмент это груминг и встреча «трёх амиго»: аналитик, разработчик и тестировщик проходят критерии на примерах, и неясности всплывают до спринта. Слишком крупную историю режьте вертикально, по сценариям, правилам или типам данных (подход SPIDR), а не на «бэкенд» и «фронтенд».

Добавьте свой пример: какую историю вы переписали и что изменилось. Цифры берите только свои, например сколько историй вернулось с тестирования до и после введения DoR. Если такого замера не было, так и скажите, это честнее придуманного процента.

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

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

Пишут критерии, которые нельзя проверить: «удобно», «интуитивно», «как в прошлой версии».

Превращают историю в полное ТЗ с описанием каждой кнопки. Пропадает Negotiable, и команда перестаёт предлагать решения проще.