Цель спринта в Scrum

Мы очень много работаем с компаниями в России, команды в которых так или иначе используют (или только собираются использовать) Scrum в качестве основы для своего процесса.

«Скрам очень прост для понимая, но очень сложен для внедрения» — так говорят сами его авторы, и это правда.

Более того, в скраме есть вещи, которые воспринимаются многими не совсем так, как это есть на самом деле. Об одном таком мифе и хочется рассказать. О цели спринта.

По-умолчанию большинство команд фокусируется на выполнении плана спринта, основанного на выбранных пользовательских историях, согласованных с продакт оунером и заказчиками. При этом для всех вокруг и для самой команды, основной критерий успеха спринта — 100% выполненных и продемонстрированных историй из списка запланированных в спринт. И если, например, одну историю не успели сделать — спринт провален, все расстроены.

Или еще хуже, считается, что в скоуп спринта нельзя вносить изменения после того, как спринт начался. А это, само собой, существенно ограничивает как заказчика, так и саму команду. И это начинает выглядеть не совсем Agile :)

Однако, если просто убрать коммитмент команды на спринт и еще позволять вносить в состав спринта изменения, получится стандартная модель Code&Fix.

На самом же деле, в скраме есть такое понятие, как Цель спринта (Sprint Goal) — некая командная установка, определяющая, зачем мы собираемся потратить следующие неделю или две, чего хотим достичь с точки зрения инкремента бизнес-ценности для заказчика. И это не просто набор запланированных пользовательских историй.

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

Успешным считается тот спринт, который достиг своей цели (ожидаемый инкремент бизнес-ценности), а не тот, в рамках которого выполнены абсолютно все запланированные истории.

Давайте посмотрим на пример такой цели, предположим, для проекта создания CRM.
Цель первого спринта может выглядеть как «Возможность заведения нового клиента», при этом в качестве историй пользователей на спринт мы можем взять (истории намеренно упрощены, но давате предположим, что они действительно трудоемкие):

  • Создание нового клиента с уникальным email
  • Создание клиента с ФИО и мобильным телефоном
  • Дополнительные атрибуты клиента: паспортные данные и адреса прописки и проживания

Начался спринт, команда работает, все хорошо.

И тут приходит заказчик и говорит, что он хочет для каждого клиента еще обязательно указывать Источник, откуда клиент попал в нашу базу. А это новая история. Можем мы взять ее в уже начавшийся спринт, ведь она изменит нам скоуп? Спрашиваем себя — новая история попадает в цель итерации? Да — отлично. Насколько вероятно, что мы успеем ее сделать в этом спринте? Кажется, что успеем — отлично, давайте возьмем и порадуем заказчика!

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

Провалили мы спринт в этом случае или нет? Давайте посмотрим на исходную цель спринта: «Возможность заведения нового клиента».

  • Мы можем показать на демо заведение нового клиента с различными атрибутами? Можем.
  • Можем получить от заказчика необходимую нам обратную связь по этой функциональности? Конечно.
  • Попали мы в исходные ожидания заказчика, пришедшего на демо? Да.
  • Заказчик доволен результатом нашей работы и проведенным демо? А то!

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

Более подробная информация о цели спринта — в оригинальном описании ScrumGuide (en) (версия 2013 года).

А вы используете цели спринта или берете на себя обязательство выполнить все запланированные истории?