Posted Tuesday, March 2, 2010 under Agile методологии.

Пару слов о критериях, которым стоит следовать при создании новых User Story.

Существует такой термин — I.N.V.E.S.T.

Данная аббревиатура состоит из первых букв шести принципов, которым стоит придерживаться при создании новой User Story:

• Independent (Независимая)
  Каждая новая User Story должна быть максимально независима от других (на сколько это возможно). Зависимости между историями делают их планирование, приоритизацию и оценку более сложными. Чаще всего, зависимостей между User Story можно избежать засчет объединения историй в одну или же разбиения на более мелкие.
• Negotiable (Подверженная изменениям/обсуждению)
  Истории нужно обсуждать и изменять если это необходимо. “Карточка” с User Story — это всего лишь краткое описание истории, которое не содержит деталей. Детали, как правило, прорабатываются на стадии обсуждения. Однако, не стоит забывать, что избыточное количество деталей может ограничивать общение с заказчиком в процессе разработки.
• Valuable (Полезная)
  Каждая, отдельно взятая история, должна приносить определенную пользу (будь-то пользователь или заказчик). Самый надежный способ сделать историю полезной — это заставить заказчика написать её. Как только заказчик осознает, что User Story это не окончательный документ на подпись, и что User Story можно обсуждать и менять, он будет чувствовать себя комфортнее при её написании.
• Estimable (Поддающаяся временной оценке)
  Разработчики должны иметь возможность оценивать истории, тем самым позволяя расставить приоритеты на итерацию. Проблемы, которые могут помешать разработчикам выполнить оценку истории: отсутствие понимания бизнес процессов (в этом случае необходимо выделять больше времени на обсуждение историй); или же история слишком большая (в этом случае требуется разбиение на более мелкие истории).
• Small (Небольшая)
  Хорошая User Story должна быть проста в реализации, обычно представляющая не более 1-й человеко/недели реализации. История, для реализации которой требуется больше времени может содержать больше ошибок связанных с масштабированием и оценкой.
• Testable (Тестируемая)
  User Story должна поддаваться тестированию. Главное помнить, мы не разрабатываем ничего что нельзя протестировать. Если вы не можете протестировать историю, вы никогда не сможете сказать готова ли она.Пример истории не поддающейся тестированию: “Программа должны быть простая в использовании”.

Источник: http://agilesoftwaredevelopment.com