User Stories пользуются широкой популярностью, почти в каждой команде, с которой я работаю, используются именно они. Однако, проанализировав почти каждый Product Backlog, становится ясно, что их часто применяют неверно.

Вместо того чтобы углубляться в правильное применение User Stories, гораздо проще выявить, как их не следует использовать. Понимая эти ошибки, станет ясно, как правильно использовать данную практику.

Давайте же смотреть на ошибки вместе!

Номер один: Использовать всю юзер стори как название PBI в вашем таск трекере
Когда я начинаю работать с командой, не зная деталей контекста, не зная личности тех, кто пишет требования и еще не видя рефайнмента, я открываю беклог и вижу.... ничего не вижу, потому что открывая беклог списком все стори начинаются одинаково и выглядят одинаково.
Просто потому, что вы используете User Story для Product Backlog Item, не значит, что заголовок должен содержать полную User Story.

Попробуйте придумать краткий заголовок, который передает суть User Story. Затем, если вы хотите узнать больше деталей, вы можете прочитать саму User Story. Помните, что заголовок всего лишь крючок, чтобы запомнить, о чем вы говорили. Заголовок не обязан охватывать всю информацию, которую вы знаете. Не делайте из всего, что вы знаете, преграду для запоминания чего-то.

Номер два: Когда все задачи = юзер стори
Если все в Product Backlog представлено в виде User Story, вы можете быть уверены, что команда неправильно использует User Stories. User Stories - это инструмент для обсуждения Пользователя и того, что он пытается достичь.

Номер три: Когда тот, кто просит, становится частью стори
Мы все видели такие User Stories:

"Как Разработчик / Владелец Продукта / Скрам-мастер / Технический Лидер / Архитектор Программного Обеспечения / Вставьте любую возможную роль, существующую в организации, здесь."

Человек, который спрашивает, не является Пользователем в User Story, если он не является Пользователем, который будет использовать ваш продукт

Номер четыре: Я, как пользователь, хочу кнопку
Ваш Пользователь не хочет просто нажимать кнопку. Он хочет достичь определенных целей. Если он может это сделать без нажатия кнопки, то это тоже замечательно!
Когда User Stories больше не являются агностичными к решению и используются как средство для описания самого решения, вы теряете преимущества User Stories, и разумно использовать что-то другое вместо них.

Что пользователь пытается достичь? Почему он стремится к этому? Как это принесет им прогресс в их жизни?
Помните, что даже если User Story - это одно предложение, это не означает, что их ситуация и стремление к получению ценности не многослойны. Не ограничивайте себя тем, что помещается в User Story. Попробуйте рассказать всю историю пользователя, а не только то, что вписывается в шаблон.

Номер пять: Когда один человек пишет стори и все
Рефайнмент, дамы и господа! И тут у меня для вас картинка. Потому что INVEST!
Если кто-то один написал не только почему, но и что и как в вашей стори, то вряд ли эта стори negotiable.