Забавная холивар-книга в стиле дневника менеджера, драматически прошедшегося по всем граблаям и слабостям (настоящим и мнимым) скрам при его внедрении в компании. Вызвала небольшую бурю в профильных agile-сообществах.

Дополняя свой пост 3-летней давности тезисами из публикации Alexander Tvar "Как писать User Story".

У хорошей юзер стори как правило:
- один actor
- одно действие
- одна ценность (value / impact)

При написании user story имеет смысл перейти с понятия ценности (value) на влияние (impact). История не обязательна должна иметь ценность, но обязательно должна оказывать влияние на актора, указанного в истории.

Классический INVEST-критерий оценки удачной юзер стори:
- Independent. Reduced dependencies = easier to plan
- Negotiable. Details added via collaboration
- Valuable
- Estimable. Too big or too vague = not estimable
- Small. Can be done in less than a week by the team
- Testable. Good acceptance criteria

Модели:
- каскадная (waterfall)
- инкрементная (инкрементальная)
- спиральная, итеративная (итерационная)

Методологии:
- RUP
- RAD
- Agile (Scrum, Kanban и проч.) и т.д.

см. правильную классификацию и как все можно смешать в кучу

Селиховкин Иван (PMLead) выложил очень толковый ликбез в четырех частях.

Читать дальше →

В последнее время для спецификации требований все чаще используют технику пользовательских историй (User story), а не вариантов использования (Use case). Однако, это не означает, что они лучше.

Пользовательские истории — это быстрый способ документирования на повседневном языке. Требование записывается в виде одной формализованной фразы, определяющей актора, потребность и ожидаемый результат (например, «As a WHO I want WHAT so that EXPECTED OUTCOME»). Такой способ экономит ресурсы на создание и поддержание требований, но требует тесного взаимодействия между исполнителем и заказчиком системы. User Story, к сожалению, не соответствует в полном объеме таким критериям «хороших требований» как полнота, однозначность и проверяемость. Хотя с этим можно бороться определяя критерии приемки.

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

UPD:
Как писать хорошие user story

UPD 2:
См. также User story vs. Job story