Sprint Planning: как сформулировать сильную Sprint Goal
Узнайте, как сформулировать значимую Sprint Goal на Sprint Planning. Сместите фокус с закрытия списка задач на поставку реальной, измеримой ценности для клиентов.
Большинство Scrum команд проводят Sprint Planning совершенно неправильно. Они переносят пачку элементов Product Backlog в Sprint Backlog, суммируют story points под свою привычную скорость, а затем судорожно пытаются придумать фразу, объединяющую десяток несвязанных задач. Руководство по Scrum 2020 года определяет первую тему Sprint Planning так: в чем ценность этого Спринта? Если пропустить этот вопрос или отвечать на него в самом конце, команда превращается в фабрику фич. Сильная Sprint Goal дает команде единую общую цель, гибкость в содержании работ и понятную причину для совместной работы.
Разница между Output и Outcome
Слабая цель описывает output, то есть сам факт выполнения работы. Она звучит примерно так: выполнить пользовательские истории 101, 102 и 104. Если история 104 не выполнена из-за падения внешнего сервиса, цель считается проваленной, даже если истории 101 и 102 уже решили главную проблему пользователя. Хуже того, закрытие всех трех задач ничего не значит, если клиенты так и не смогли достичь нужного результата.
Сильная цель описывает outcome, то есть измеримый результат или изменение состояния системы. Например: дать гостям возможность оплачивать заказ через цифровые кошельки, чтобы снизить отток на этапе оформления. Теперь у Developers есть четкий ориентир. Если из-за сложностей с интеграцией один из платежных провайдеров окажется недоступен на этой неделе, команда сможет заменить его другим и не провалить Sprint. Обязательство берется перед Sprint Goal, а не перед неизменным планом.
Начните с первой темы
Руководство по Scrum выделяет три ключевые темы для Sprint Planning: почему этот Спринт ценен, что может быть сделано за этот Спринт, как будет выполняться выбранная работа. Если следовать этому порядку, формулирование цели перестает быть проблемой.
Product Owner приходит с задачей, основанной на Product Goal. Он объясняет, почему этот Спринт важен для продукта. Затем Scrum команда совместно формулирует Sprint Goal до того, как наберет конкретные задачи. Когда команды начинают сразу с задач, в итоге неизбежно рождаются монструозные цели Франкенштейна, сшитые множеством союзов «и».
Признаки слабой Sprint Goal
Оценить жизнеспособность вашей Sprint Goal можно с помощью простых вопросов во время планирования:
- Содержит ли цель союз «и» три раза подряд, пытаясь склеить воедино несвязанные проекты?
- Считается ли цель проваленной, даже если вы предоставили реальным пользователям полезный рабочий продукт?
- Лишает ли цель команду Developers возможности скорректировать объем работ при возникновении технических неожиданностей?
- Поймет ли клиент или руководитель компании, ради чего стоит финансировать эту цель?
Если ваша цель напоминает список покупок, у вас нет цели. У вас есть маршрутный лист. А маршрутный лист теряет смысл в первую же минуту, как только вы попадаете в пробку.
Как быть с разноплановой работой и поддержкой
Часто приходится слышать возражение: некоторые команды поддерживают несколько устаревших систем или тратят половину времени на баги, как же им сформулировать единую цель? Если у команды десять абсолютно не связанных задач, попытка вымучить искусственную цель вроде «повысить стабильность во всех приложениях» принесет только вред. Это порождает цинизм.
В таких ситуациях сфокусируйте цель на одном, самом критичном результате Спринта. Выделите под эту цельную задачу реалистичную долю доступного времени, а остальную емкость направьте на рутинное обслуживание. Sprint Goal отражает главный показатель, который необходимо сдвинуть с места. Если в продакшене случится авария, команда будет точно знать, чем пожертвовать в первую очередь, а что нужно защищать любой ценой.
Ежедневный ориентир и подлинная гибкость
Sprint Goal создается не для того, чтобы забыть о ней до самого Sprint Review. Это компас для каждого Daily Scrum. Developers ежедневно оценивают свое продвижение к Sprint Goal. Если темп падает, они адаптируют план. Команда может отказаться от менее приоритетных элементов Product Backlog, сохранив при этом саму цель.
Именно в этом и заключается настоящая гибкость. Гибкость состоит не в том, чтобы закрыть шестьдесят story points точно по графику. Гибкость означает способность адаптировать детали реализации, сохраняя неизменный фокус на создании ценности для клиентов.