Применяются для упрощения понимания требований. Представляют собой короткие описания функциональности от имени пользователя

Зачем нужен

User Story упрощают понимание функциональных требований для всех участников проекта

Когда применять

• Когда меняются требования к проекту
• При верхнеуровневом описании сложной функциональности
• При необходимости вовлечения заинтересованных сторон

Как применять

Формат User Story позволяет описывать требования в виде, который понятен и команде клиента, и команде разработки.

Требования от имени конкретного пользователя позволяет сразу выделить заинтересованные стороны и расставить приоритеты задачам

Когда не работает

• В проектах с высокой степень неопределенности
• Для описания нефункциональных требований

Детальное описание

Рекомендуемый формат

Обычно составляется по формуле:

“Я как [1] хочу [2], чтобы [3]”, где

1 – тип пользователя, персонаж

2 – действие или цель

3 – результат или ценность

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

Критерии хорошо сформулированных User Story

Пользовательские истории должны соответствовать критериям INVEST:

Independent (Независимые) – описываемые в User Story функции должны быть независимыми и решать сформулированную проблему пользователя без помощи других инструментов

Negotiable (Обсуждаемые) – User Stories должны быть достаточно гибкими, чтобы их можно было изменять и дополнять

Valuable (Ценные) – каждая описанная в истории функциональность должна нести какую-то ценность

Estimable (Оцениваемые) – разработчики должны иметь возможность оценить сложность и объем разработки

Small (Маленькие) – истории должны быть краткими и емкими

Testable (Тестируемые) – команда должна понимать, как тестировать и проверять описанную в User Story функциональность

 

 

Связанные артефакты

• Use cases (примеры использования)