Цель Спринта упоминается много раз в Scrum Guide, однако многие команды игнорируют её. Или же вспоминают о цели в последний момент и выдумывают нечто нелепое. Нам приходилось наблюдать ситуации, когда цель никак не рождалась. Часто разработка заходит в тупик и целью становится «Просто сделать всё!»
Цель нужна для того, чтобы сфокусировать команду разработчиков во время спринта. Если целью является просто выполнение задач из бэклога, то команда будет изолировано работать над своей областью, а члены команды идти в разных направлениях. Это не то, о чём мы говорим, когда хотим поставить инкремент в конце спринта.
Если вы сталкиваетесь с проблемой, когда значимую цель сложно выбрать, понять и сформулировать, эта статья вам поможет.
Самый стандартный шаблон по аналогии с User Story:
Мы хотим выпустить/добиться "X" (значимый инкремент, описанный верхнеуровнево),
что поможет клиенту/пользователю получить "Y".
или
Наше внимание сосредоточено на <Outcome>
Мы считаем, что это приносит <Impact> для <Customer>
Это будет подтверждено, когда <Событие произойдет>
Мы пробовали эти шаблоны несколько раз, когда было сложно определить то направление, в котором двигалась команда.
На примере из жизни это выглядит так:
- Наша цель — построить аккуратный гараж, в который мы можем поставить машину.
- Мы считаем, что это снизит риск угона автомобиля и повысит наше спокойствие.
- Это будет подтверждено, когда машину можно будет поставить в гараж и она будет не видна с улицы.
Может звучать нелепо или натянуто, но подобный шаблон помогает разобраться в винегрете из пользовательских историй.
- Мы сосредоточены на создании нового лендинга для маркетинговой акции.
- Это позволит отделу маркетинга организовать успешную акцию и удобнее организовывать активности и собирать статистику.
- Это будет подтверждено, когда стейкхолдеры примут новый лендинг.
Плохие примеры будут из разряда:
- Нам нужно завершить все элементы спринта для новой интеграции.
- Это удовлетворит стейкхолдеров и позволит нам уложиться в дедлайн.
- Это будет подтверждено, когда эпик будет закрыт в Jira.
Это плохо, потому что такие формулировки привязывают вас к конкретным эпикам и созданным задачам. Из-за этого теряется вариативность, и это тоже самое, что использовать "не цель" — завершить все ASAP.
Если шаблон не помогает
Это сигнал к тому, чтобы пересмотреть состав и назначение команды и приоритеты по продукту. В нашей практике это основные причины. Часто проблемы возникают у платформенных команд или команд техподдержки, которые работают по Scrum. В этом случае можно пробовать брать цели, связанные не с выпуском инкремента, а связанные с построением команды, внедрением инженерных практик, улучшение метрик/перфоманса.