User story (пользовательская история)

User story (пользовательская история) — короткое описание функции с точки зрения того, кому она нужна. Классический шаблон:

Как <роль>, я хочу <действие>, чтобы <получить ценность>.

Например: «Как менеджер проекта, я хочу видеть задачи спринта на доске, чтобы быстро оценивать прогресс». История описывает не техническое решение, а потребность пользователя — что и зачем, оставляя как команде.

Зачем нужны истории

• Фокус на ценности. Формулировка «чтобы…» заставляет ответить, зачем вообще делать функцию.
• Общий язык. Истории понятны и заказчику, и команде — в отличие от технических спецификаций.
• Удобный размер. История — это единица работы, которую обычно можно сделать за один спринт.

Критерии приёмки

К истории прикладывают критерии приёмки — список условий, при которых она считается выполненной. Они превращают расплывчатое «хочу видеть задачи» в проверяемые пункты: какие поля показывать, что происходит при пустом списке, как фильтровать. Критерии приёмки — основа для тестирования (см. тест-менеджмент в справке).

Истории, эпики и задачи

• Эпик — крупная потребность, которая не влезает в один спринт; разбивается на истории.
• User story — функция глазами пользователя, помещается в спринт.
• Задача (task) — конкретный технический шаг внутри истории.

INVEST — признаки хорошей истории

Хорошая история: Independent (независимая), Negotiable (обсуждаемая), Valuable (ценная), Estimable (оценимая), Small (небольшая), Testable (проверяемая).

Оценка

Истории обычно оценивают не в часах, а в стори-поинтах — относительной мере трудоёмкости.

В KvaTask

В KvaTask истории удобно вести как задачи типа «story» с подзадачами, критериями приёмки в описании и связью с эпиком. Типы задач настраиваются под проект.