Планирование спринта

Перевод оригинальной статьи Stefan Wolpers "Scrum: 20 Sprint Planning Anti-Patterns"
Автор перевода Толкачёва Валерия, Scrum Master (Telegram: @Val1eriya)

Планирование спринта — это основное событие, которое определяет, как улучшится жизнь ваших клиентов с помощью следующего инкремента продукта. Узнайте больше о том, как повысить его эффективность, избегая 20 распространенных антипаттернов Планирования спринта.

Цель Планирования спринта

Цель Планирования спринта в Scrum – согласовать действия разработчиков и Владельца продукта по поводу того, что будет создаваться в следующем спринте, чтобы принести максимальную ценность клиентам.

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

С версии руководства по Scrum 2020 года требование о том, чтобы Scrum-команда обязательно решала хотя бы одну высокоприоритетную проблему, выявленную на предыдущей Ретроспективе спринта, было упразднено.

Руководство по Scrum характеризует Планирование спринта следующим образом:

Sprint Planning инициирует Sprint, планируя работу, которую необходимо выполнить в этом Sprint. Результатом события становится план, созданный совместными усилиями всей Scrum-команды.

Product Owner обеспечивает готовность участников к обсуждению наиболее важных элементов Product Backlog и их связи с Product Goal. Scrum-команда может приглашать на Sprint Planning для консультаций и других людей.

По сути, Планирование спринта отвечает на три вопроса:

1.Почему этот Sprint ценен? (Product Owner предлагает, как можно повысить ценность и практичность продукта в текущем Sprint. Затем вся Scrum-команда совместно определяет Sprint Goal, которая объясняет, почему Sprint ценен для заинтересованных лиц. Sprint Goal должна быть сформулирована до окончания Sprint Planning.)

2.Что может быть готово в этом Sprint? ( Developers обсуждают с Product Owner, какие элементы Product Backlog выбрать для включения в текущий Sprint. Scrum-команда может попутно уточнять эти элементы, чтобы улучшить понимание и повысить уверенность. Выбор элементов, которые получится завершить за Sprint, может оказаться трудной задачей. Однако, чем больше Developers знают о своей прошлой производительности, своих возможностях на следующий Sprint и своем определении готовности, тем более уверенно они могут прогнозировать работу на следующий Sprint.)

3.Как будет выполняться выбранная работа? (Developers для каждого выбранного элемента Product Backlog планируют работу, необходимую для создания Increment, соответствующего определению готовности. Это часто делается путем декомпозиции элементов Product Backlog на более мелкие задачи продолжительностью не более одного дня. То, как это делается, остается на усмотрение разработчиков. Никто не указывает им, как превращать элементы Product Backlog в Increments ценности. Sprint Goal, выбранные элементы Product Backlog, плюс план их реализации вместе называются Sprint Backlog.)

Источник: Руководство по Scrum 2020.

Если Scrum-команда успешно использует методы уточнения Бэклога продукта для создания и поддержания актуального Бэклога продукта, то Планирование спринта занимает гораздо меньше времени, чем восемь часов, указанные в Руководстве по Scrum для месячного спринта. По сути, разработчики и Владелец продукта корректируют ранее обсужденный объем предстоящего спринта в соответствии с доступными ресурсами.

Кроме того, могла появиться новая важная задача, которую Владелец продукта также хочет включить в следующий спринт. Следовательно, некоторые из ранее рассмотренных элементов Бэклога продукта не попадут в Бэклог спринта. Хорошая Scrum-команда может справиться с этим за 10-30 минут, прежде чем перейти к декомпозиции задач и первоначальному планированию того, как разработчики намерены выполнить работу спринта.

Антипаттерны Планирования спринта

Существует три категории антипаттернов Планирования спринта. Они касаются разработчиков, Владельца продукта и Scrum-команды.

Антипаттерны Планирования спринта разработчиков

Производительность? Разработчики переоценивают свои возможности и берут на себя слишком много задач. (Вместо этого разработчики должны учитывать все, что может повлиять на их способность выполнить работу. Список таких факторов длинный: государственные праздники, новые члены команды и те, кто находится в отпуске, увольняющиеся члены команды, члены команды, находящиеся на больничном, корпоративные расходы, Scrum-события, например уточнение Бэклога продукта, и другие встречи, и это лишь некоторые из факторов.)

Какой технический долг? Разработчики не требуют достаточного времени для решения проблемы технического долга и исправления ошибок, а также для поддержания стандарта качества продукта. Вместо этого они полностью принимают модель "фабрики функций", выпуская одну новую функцию за другой. (Мое эмпирическое правило заключается в том, что разработчики должны рассмотреть возможность выделения до 20% своего времени на исправление ошибок и рефакторинг кодовой базы. Высококачественный технологический стек лежит в основе способности Scrum-команды адаптировать следующие шаги к извлеченным урокам и последним рыночным тенденциям. Техническое совершенство является необходимым условием любой формы бизнес-гибкости; сохранение этого состояния - это непрерывный процесс, требующий постоянных и существенных инвестиций. Читайте подробнее: Технический долг и Scrum.)

Нет свободного времени. Разработчики не требуют от Владельца продукта 20% свободного времени. (Это связано с Планированием спринта, созданием Целей спринта и способностью команды к прогнозированию. Если мощность команды всегда используется на 100%, ее производительность снизится. Каждый будет сосредоточен на выполнении своих задач. Будет меньше времени на поддержку товарищей по команде или на парное программирование. Незначительные проблемы больше не будут решаться быстро. И, в конечном итоге, отношение "я занят" уменьшит создание общего понимания среди всех членов команды, почему они делают то, что делают.)

Слишком детальное планирование. Во время Планирования спринта разработчики заранее планируют каждую отдельную задачу предстоящего спринта. (Не увлекайтесь чрезмерной детализацией. Одной четверти задач более чем достаточно не только для начала спринта, но и для начала обучения. Бэклог спринта является эмерджментным/внезапно возникающим, и слишком большое предварительное планирование может привести к потерям. Scrum - это не ограниченная по времени форма практики планирования водопада.)

Слишком много оценок. Разработчики оценивают даже подзадачи. (Для меня это выглядит как учет ради учета. Так что не тратьте на это время. Помните: цель оценки состоит в том, чтобы выявить несогласованность среди разработчиков относительно того, что и как делать с элементами из Бэклога продукта или Бэклога спринта. Подробнее: Оценки полезны, просто откажитесь от цифр.)

Слишком мало планирования. Разработчики полностью пропускают планирование. (Пропуск планирования - это плохо, так как это также отличная возможность поговорить о том, как распространять знания среди разработчиков, куда движется архитектура или являются ли инструменты адекватными. Например, команда может также подумать о том, кто с кем будет работать в паре над какой задачей. Часть планирования разработчиков также хорошо подходит для рассмотрения того, как уменьшить технический долг, см. выше.)

Руководители команды? Разработчики не создают план совместной работы. Вместо этого «руководитель команды» выполняет всю тяжелую работу и, возможно, даже назначает задачи отдельным разработчикам. (Я знаю, что старшим разработчикам не нравится эта идея, но в Scrum-команде нет «руководителя команды». Читайте подробнее: Почему инженеры презирают Agile.)

Антипаттерны Планирования спринта Владельца продукта

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

Нет бизнес-цели, нет Цели спринта, просто случайные вещи. Владелец продукта предлагает направление, которое напоминает случайный набор задач, не обеспечивая согласованности. Следовательно, Scrum-команда не создает Цели спринта. (Если это естественный способ завершения вашего Планирования спринта, вы, вероятно, пережили полезность Scrum как фреймворка разработки продукта. В зависимости от зрелости вашего продукта Kanban может оказаться лучшим решением. В противном случае случайность/хаотичность может сигнализировать о слабом Владельце продукта, который слишком много слушает стейкхолдеров вместо того, чтобы составлять и упорядочивать Бэклог продукта соответствующим образом.)

Незаконченные дела. Незаконченные пользовательские истории и другие элементы из прошлого спринта переходят в новый спринт без какого-либо обсуждения. (Для этого могут быть веские причины, например, ценность задачи не изменилась. Однако это не должно быть автоматизмом; помните о заблуждении невозвратных затрат.)

Изменения в последнюю минуту. Владелец продукта пытается втиснуть в последнюю минуту некоторые пункты Бэклога продукта, которые еще не были доработаны. (В принципе, это прерогатива Владельца продукта - вносить такого рода изменения, чтобы гарантировать, что разработчики работают только над самыми ценными задачами в любой момент времени. Однако, если Scrum-команда в остальном регулярно практикует уточнение Бэклога продукта, эти случаи должны быть редким исключением. Если это происходит часто, это указывает на то, что Владельцу продукта нужна помощь в упорядочении Бэклога продукта и улучшении коммуникации в команде. Или Владельцу продукта нужна поддержка, чтобы справиться с напористыми стейкхолдерами.)

Фокус на объёме. Владелец продукта заставляет разработчиков взять на себя больше задач, чем они реально могут выполнить. Вероятно, Владелец продукта ссылается на прошлые показатели команды, такие как скорость (velocity), чтобы обосновать своё желание. (Это также путь к превращению в фабрику функций и заслуживает внимания Scrum-мастера команды. Это нарушает прерогативу разработчиков выбирать элементы Бэклога продукта для Бэклога спринта и ценности Scrum.)

Отсутствие подготовки. Проблема возникает, когда Владелец продукта не уделяет достаточного внимания постоянному уточнению и актуализации Бэклога продукта совместно с командой разработчиков. Бэклог продукта должен отражать наиболее эффективное использование времени разработчиков с точки зрения ценности для клиента в любой момент времени. Другими словами, Бэклог продукта Scrum-команды должен быть готов к использованию 24/7. Это означает, что команда должна быть способна начать Планирование спринта в любой момент, имея четкое представление о приоритетах и задачах. Подготовка нескольких пунктов Бэклога продукта за час до начала Планирования спринта является недостаточной и свидетельствует о недостаточном внимании к этому важному аспекту работы.

Антипаттерны Планирования спринта Scrum-команды

Непостоянная длительность спринтов. Еще один распространенный антипаттерн - это вариативность длительности спринтов. Например, задачи не подгоняются под стандартную длительность спринта, а наоборот, длительность спринта адаптируется к размеру задач или текущей цели спринта. Хотя гибкость в Scrum приветствуется, изменение длительности спринта "по необходимости" является признаком неэффективного управления Бэклогом продукта и процесса разработки. Вместо того, чтобы менять длительность спринта для соответствия Цели спринта, Scrum-команда должна уделить больше внимания правильному разбиению задач на более мелкие и управляемые элементы. Стоит отметить, что длительность спринта может изменяться в зависимости от контекста, например, при крутой кривой обучения или в периоды отпусков, но это должно быть обоснованным и согласованным решением команды, а не реакцией на проблемы с планированием.

Чрезмерные обязательства. Scrum-команда регулярно берет на себя слишком много задач и переносит незавершенную работу напрямую в следующий спринт. Хотя перенос нескольких задач (2-3) в следующий спринт при достижении Цели спринта может быть приемлемым, систематический перенос 30-40% первоначального плана говорит о проблемах с оценкой задач и планированием спринта. Такая ситуация может указывать на то, что команда фактически использует "Kanban с временными рамками" вместо Scrum. В этом случае, стоит рассмотреть переход на Kanban как на более подходящую альтернативу. Если же команда предпочитает остаться в рамках Scrum, необходимо уделить больше внимания уточнению Бэклога продукта, формированию реалистичных Целей спринта и улучшению навыков оценки задач.

"Stage-Gate®" по определению готовности (DoR). Scrum-команда решает, что "определение готовности" (DoR) - это полезный инструмент, но применяет его догматично, создавая тем самым процесс утверждения, подобный Stage-Gate®. ( Это интересная тема для обсуждения внутри команды. Например, стоит ли откладывать ценную пользовательскую историю на другой спринт только потому, что дизайн интерфейса будет готов через два рабочих дня? Мое предложение: вынесите этот вопрос на обсуждение с командой. Если они согласны с обстоятельствами и принимают соответствующий элемент Бэклога продукта в спринт — это нормально. Однако, если "определение готовности" используется как контрольный список, отклоняя все, что не покрыто на 100%, то это фактически возвращает команду к водопадной модели, только на этот раз инициатором является сама команда разработчиков.) Читайте подробнее: Опасности определения готовности.

Отсутствие стандарта готовности элементов Бэклога продукта. У Scrum-команды нет общего понимания того, какие требования должен удовлетворять элемент Бэклога продукта, чтобы считаться "готовым к спринту". Это противоположная крайность догматичному применению "определения готовности". В такой ситуации, разработчики могут выбирать неподходящие рабочие элементы, которые могут вызвать ненужные сбои во время спринта и даже поставить под угрозу достижение Цели спринта. Полное отсутствие стандартов готовности также не является эффективным подходом.

Навязанный прогноз. Прогноз спринта не является решением, принятым командой, или находится под внешним влиянием. Здесь существует несколько анти-паттернов. Например, властный Владелец продукта доминирует над разработчиками, определяя объем их прогноза. Или стейкхолдер указывает на предыдущую скорость команды, требуя взять на себя больше пользовательских историй ("Нам нужно заполнить свободную емкость (capacity)"). Или "технический лидер" разработчиков делает прогноз от имени всех остальных.

Игнорирование планирования. Разработчики не участвуют коллективно в Планировании спринта. Вместо этого команду представляют, например, два члена команды - "технический лидер" и "UX лидер". (Что касается идеи одного или двух "ведущих" членов команды в Scrum-команде, то их нет, см. выше). И если вы не используете Nexus или LeSS, где команды проводят общее Планирование спринта, то вся Scrum-команда должна участвовать. Это командная работа, и поэтому голос каждого должен быть услышан. В противном случае пострадает прозрачность и могут быть приняты ошибочные решения, что снизит создание ценности и увеличит риски.

Антипаттерны Планирования спринта Scrum-мастера

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

Помимо соучастия в описанных выше анти-паттернах Планирования спринта, не обращая на них внимания, я могу придумать один анти-паттерн Планирования спринта, который напрямую относится к ответственности Scrum-мастера. Несмотря на изменения в Руководстве по Scrum в 2020 году, решение важной проблемы улучшения из предыдущей Ретроспективы спринта в каждом спринте по-прежнему является важным шагом, помогающим Scrum-команде непрерывно совершенствоваться. Поэтому, на мой взгляд, неспособность поддержать Scrum-команду в этом вопросе является анти-паттерном Планирования спринта.

Заключение

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

Какие анти-паттерны планирования спринта вы наблюдали? Пожалуйста, поделитесь этим с нами в комментариях.

20 антипаттернов Планирования спринта