Обязательные поля

  • ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.
  • Название (Name) — краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и хозяин проекта могли понять, о чем идёт речь и отличить одну историю от другой.
  • Важность (Importance) — степень важности данной истории, по мнению хозяина проекта. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.
  • Предварительная оценка (initial estimate) — начальная оценка объёма работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».
  • Как продемонстрировать (how to demo) — краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо-сдаточного испытания.

Дополнительные поля

Иногда, также, используются дополнительные поля в резерве проекта, в основном для того, чтобы помочь хозяину проекта определиться с его приоритетами.

  • Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля хозяин проекта может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.
  • Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений.
  • Инициатор запроса (requestor). хозяин продукта может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.
  • ID в системе учёта дефектов (bug tracking ID) — если вы используете отдельную систему отслеживания ошибок, тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.

Встречи

Планирование спринта (Sprint Planning Meeting)

Происходит в начале новой итерации Спринта.

  • Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;
  • На основе выбранных задач создается резерв спринт. Каждая задача оценивается в идеальных человеко-часах;
  • Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
  • Обсуждается и определяется, каким образом будет реализован этот объём работ;
  • Продолжительность совещания ограничено сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
    • (первая часть совещания) Участвует хозяин проекта и скрам команда: выбирают задачи из резерва продукта;
    • (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют резерв спринта.