Вспомним, что о Цели спринта (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 и потенциально даже делает его бесполезным.
Не старайтесь убедить или заставить людей формулировать цель - лучше обратите внимание на выяснение и устранение препятствий на пути к этому.
Update 21-Oct-2022
В статье пользователя burnitblue про работу Скрам-мастера "Как быть скрам-мастером, если ты не скрам-мастер" описан немного отличный от канонического подход к работе с целью спринта:
В каноническом скраме предполагается, что скрам-команда (владелец + разработчики) формулируют цель спринта, исходя из поставленной бизнес-задачи, после чего команда разработки самостоятельно выбирает задачи, которые позволят достигнуть этой цели, и (здесь внимательно!) совместно «набрасывается» на нее в течение всех 1-2-N недель.
Стоит ли говорить, что такая каноническая ситуация возможна в современных реалиях не всегда? Некоторые компании не могут позволить себе взять одну цель на спринт и отвести на нее 100% своих ресурсов, т.к. заказчиков и потребностей достаточно много. Таким образом, одна команда в течение спринта может быть занята тематически разными задачами. В таком случае, можно использовать «цель спринта» в качестве «фокуса спринта». Как говорится, «все равны, но я равнее» — в случае возникновения трудностей, именно на задаче-фокусе стоит сконцентрироваться при прочих равных.
Конкретно в нашем случае фокус спринта очень помогал команде, когда тимлидам (которые являются активными разработчиками) нужно было отвлечься от задачи для того, чтобы помочь своим коллегам, например, в парном программировании или просто консультационно. На daily scrum (он же стендап) я старалась мягко вернуть команду к фокусу, что уместно, даже если внефокусные задачи не будут закрыты вовремя.
Не является ли понятие «фокуса спринта» отговоркой для того, чтобы сделать какую-то одну большую задачу, а не закрыть спринт целиком? Буду капитаном: зависит от вас. Фокус спринта является инструментом для приоритизации при возникновении сложных ситуаций и нехватке ресурсов (недооценили задачи, появились новые вводные, кто-то заболел и т.д.).
Здесь мне кажется ситуация именно такая, а которой говорили в руководстве авторы: Изменение ключевых идей или структуры Scrum, исключение каких-либо элементов или не
следование правилам Scrum приводит к сокрытию проблем, ограничивает преимущества Scrum и потенциально даже делает его бесполезным.
Вероятно в команде есть какие-то проблемы, не позволяющие регулярно достигать цели спринта. То есть, по сути, команда не поставляет бизнесу тот результат, который был запрошен РО (Владельцем продукта) и под которым "подписалась" команда на спринт. Возможно это отвлечения членов команды на другие активности, возможно заказчик проталкивает в бэклог спринта какие-то "очень срочные" задачи, из описания не очень понятно. Но вместо того чтобы искать и устранять причины таких проблем, похоже что команда в инициативном порядке превратила цель спринта в желательную, но необязательную. Это оставляет команде психологический запасной выход на случай неудачи — да, мы не справились, но мы и не обещали.
