Как сформулировать сильную Sprint Goal на Sprint Planning
Узнайте, как создать четкую и ценную Sprint Goal на встрече Sprint Planning. Разберитесь, почему единая цель эффективнее случайного набора задач, и как команде сохранять фокус.
Большинство сессий Sprint Planning терпят неудачу в самом начале, потому что команды воспринимают их как инвентаризацию. Разработчики набирают из трекера десяток разрозненных задач, высчитывают доступные часы до минуты и считают планирование завершенным. Когда кто-то спрашивает, в чем заключается Sprint Goal, Scrum Master пытается слепить три предложения, упомянув каждую отдельную задачу из Backlog. Это полностью противоречит самой сути Scrum.
Первая тема задает направление
Руководство по Scrum 2020 года делит Sprint Planning на три отдельные темы. Первая тема поднимает простой вопрос: почему этот Sprint ценен? Прежде чем выбирать элементы или оценивать трудозатраты, Product Owner предлагает гипотезу, как продукт может увеличить свою ценность и пользу в предстоящем спринте. Затем вся Scrum Team совместно формулирует Sprint Goal, которая объясняет заинтересованным сторонам важность этого спринта.
Если пропустить это обсуждение, получается спринт сборная солянка. Участники команды изолированно работают над своими задачами. При возникновении непредвиденных технических сложностей никто не понимает, от чего можно отказаться. В итоге люди перерабатывают или жертвуют качеством, пытаясь дотянуть каждую задачу до финиша.
Что делает цель по-настоящему сильной
Сильная Sprint Goal едина, ориентирована на бизнес и гибка. Она описывает конечный результат для пользователя или бизнеса, а не просто объем выполненной работы. Когда цель сосредоточена на ценности, у разработчиков остается пространство для маневра, чтобы передоговориться с Product Owner об объеме конкретных задач по мере появления новых вводных в течение спринта.
- Она описывает конкретное изменение возможностей пользователя, например, оформление заказа с сохраненной банковской картой.
- Она задает единый критерий успеха, который не зависит от закрытия всех задач из Backlog.
- Она формирует общую ответственность среди разработчиков вместо индивидуальной привязки к отдельным задачам.
- Она легко укладывается в одно емкое предложение, понятное любому человеку за пределами команды.
Слабые цели против сильных
Почувствуйте разницу между списком задач и настоящей целью. Слабая цель звучит так: закрыть пользовательские истории 102, 104 и 108, исправить баги в оформлении заказа и обновить схемы базы данных. Такая формулировка не дает никаких ориентиров, когда приходится идти на компромиссы. Если миграция базы данных займет вдвое больше времени, чем планировалось, что команда должна защищать в первую очередь?
Сильный вариант для того же спринта мог бы звучать так: подключить регулярные платежи по подписке для клиентов из Европы. Теперь у команды есть ориентир. Если создание собственного интерфейса оплаты окажется слишком сложным, разработчики могут временно использовать стандартную готовую форму, чтобы достичь цели. Конкретные задачи меняются, но суть и замысел остаются неизменными.
Правило гибкости
Scrum Guide проводит четкое различие: Sprint Goal является обязательством, а вот объем запланированной работы им не является. По ходу спринта разработчики неизбежно сталкиваются со скрытыми сложностями. В такой ситуации они не бросают цель втайне от всех. Напротив, они обсуждают ситуацию с Product Owner и корректируют Sprint Backlog без ущерба для Sprint Goal.
Если цель сводится к закрытию всех запланированных задач, эта гибкость исчезает. Любой незавершенный тикет становится провалом. Настоящая цель дает разработчикам свободу решить проблему самым простым и жизнеспособным способом, найденным в процессе работы.
Как фасилитировать обсуждение цели
Начинайте Sprint Planning с анализа Product Goal и текущего состояния Increment продукта. Product Owner представляет бизнес-цель или гипотезу на предстоящий спринт. Дайте разработчикам возможность критически осмыслить эту задачу. Спросите себя: если бы мы могли выпустить только одно ценное улучшение за этот спринт, что бы это было?
Сформулируйте черновик цели до того, как начнете набирать задачи. Как только команда согласует формулировку, выберите из Backlog только те элементы, которые напрямую работают на эту задачу. Оставшиеся ресурсы можно оставить под текущие технические задачи, но все должны понимать, что Sprint Goal имеет наивысший приоритет.