Нужна ли команде Цель спринта в Scrum?

Вспомним, что о Цели спринта (Sprint Goal) говорится в официальном руководстве по Scrum:

Sprint Goal — единственная цель на Sprint. Несмотря на то, что Developers привержены Sprint Goal, она обеспечивает гибкость с точки зрения выбора конкретной работы, необходимой для ее достижения. Sprint Goal также обеспечивает связность и сфокусированность, побуждая Scrum Team работать совместно, а не над отдельными инициативами.

Sprint Goal создается во время Sprint Planning, а затем добавляется в Sprint Backlog. Developers помнят о Sprint Goal в ходе работы над задачами Sprint. Если работа не соответствует ожиданиям, они взаимодействуют с Product Owner, чтобы пересмотреть содержание Sprint Backlog в рамках Sprint, не изменяя Sprint Goal….

В ходе Sprint Planning … вся Scrum Team совместно определяет Sprint Goal, которая объясняет, почему Sprint ценен для заинтересованных лиц. Sprint Goal должна быть сформулирована до окончания Sprint Planning.

Можно определить несколько преимуществ от использования Цели спринта:

• четкий фокус команды во время работы на достижении цели

• критерий для внесения изменений в работу (помогут ли они достижению цели или наоборот помешают)

• мотивирующий фактор в работе, побуждающий в том числе к взаимопомощи и командной работе

• прозрачность работы команды для заинтересованных лиц (stakeholders)

• критерий определения эффективности работы на обзоре спринта и ретро-сессии

Но определение цели на спринт может быть достаточно сложным для команды, многие команды испытывают трудности с этим. А ведь это регулярный процесс, на каждом планировании спринта приходится это делать (в среднем плюс-минус раз в две недели). Если сама команда не видит пользы от этого артефакта и считает формулировку цели пустой тратой времени, делать они это, скорее всего, не будут. В итоге, после нескольких начальных спринтов в проекте (по опыту, первоначального запала хватает от 1-2 мес до полугода) либо на это все забивают с аргументацией: «Мы не можем брать на себя такое обязательство, все эти строгие цели и дедлайны это не Agile«, «В нашей команде это не работает«, «Клиенту на эти цели пофиг, значит нечего тратить на них время«и т.п. Либо цель определяет владелец продукта / менеджер в приказном порядке (в командах, работающих на «ручном управлении»).
Иногда цель спринта становится мульти-целью, когда команда не может определить что главное для клиента, какую пользу ему принесет этот инкремент, и включает в Sprint goal несколько пунктов. Не говоря уже о Цели 80-го Уровня: «Закрыть все эти чертовы таски за этот спринт!«

Отсутствие четкой цели на спринт может привести к тому, что команда потеряет фокус, что же важно сделать за спринт, каждый будет делать те задачи, которые ему кажутся сейчас приоритетными («кто в багфиксинг, кто за техдолгом«). В итоге на спринт ревью и ретроспективе вместо обсуждения прогресса в достижении Цели спринта, члены команды откупаются ничего не значащими фразами «вроде всё норм, всё как всегда, замечаний нет». Про предлагаемые улучшения, которые в идеале должны быть по итогам ретро-сесии добавлены в бэклог, и говорить не приходится.

Встречал такие проекты и команды на практике, итог практически всегда предсказуем — расфокусировка команды, быстрая потеря мотивации у разработчиков, отсутствие улучшений в работе, постоянный перенос незавершенных задач на следующий спринт, поставка нового релиза раз в 2-3-4 месяца. И вот уже у вас вместо Скрама лишь пустой по сути карго-культ, и руководство ищет на замену нового менеджера или Скрам-мастера, потому что этот «поломался«…

Между тем, вместо того чтобы убеждать команду «старайтесь получше, чтобы сформулировать хорошую Цель спринта», можно обратить внимание, какие есть препятствия в формулировке релевантной Sprint Goal. Команда опасается негативных последствий в случае не достижения цели. Слишком короткие спринты. Владельцу продукта не хватает полномочий. Слишком много внешних зависимостей. Склонность высшего руководства или клиентов набрасывать «срочные очень приоритетные» задачи.

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

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

Не старайтесь убедить или заставить людей формулировать цель — лучше обратите внимание на выяснение и устранение препятствий на пути к этому.