Что обязательно должно быть в User Story

Самая интересная штука в Scrum, это Пользовательские истории или User Story. Никаких Вам технических заданий, распоряжений или, ужас какой, приказов.

Небольшая карточка с одним предложением:

Как … я хочу ….чтобы

Ну вернее много карточек, конечно.

3 правила написания User Story:

1. Краткость. Это всегда одно, максимум два предложения. Поэтому и придумали использовать небольшие карточки, чтобы не получалось много написать.

2. Обычный язык. Знаете или не знаете сложные термины  — в пользовательских историях пишите языком пользователя или заказчика.

3. Компактность требований. В идеале, одна User Story формулирует одно конкретное и небольшое требование. Дробить задачи стоит аккуратно. Уменьшать требования до функции выбора цвета кнопки в итоге обойдется себе дороже. Рекомендуется ориентироваться на объем работа, которые укладываются в период одного спринта.

Карточки с User Story оформляются и в электронном и в бумажном форматах. Распространение получил симбиоз — все карточки обязательно сохраняются в цифровом варианте, а для текущей работы в спринте используются бумажные версии.

Теоретически, каждая команда может самостоятельно определить критерии пользовательских историй и их формат. Все зависит от направления работ и тематики проектов. Главное, потом придерживаться этих форматов внутри одного проекта.

Формула: >>>Как … я хочу … чтобы …<<<

состоит из трех частей:

КАКэто заказчик или конечный пользователь результатов проекта.

Я ХОЧУ —  примечание, чтобы увидеть глазами пользователя конечный результат задачи

ЧТОБЫитоговая цель для чего задача исполняется.

Пример:

КАК подписчик Я ХОЧУ видеть название каждой строки при вводе личной информации ЧТОБЫ знать какую именно информацию мне нужно вводить.

Формулу можно дополнять, но убирать из нее элементы не рекомендуется.