Как долго должна длиться встреча по планированию спринта?

По вашему опыту, как долго должна длиться встреча по планированию спринта (Scrum)? 8 часов? Или это должно быть короче (лаконично), и дальнейшие обсуждения должны быть запланированы как часть спринта? Наши спринты 10 дней.

Согласно Scrum Guide :

Совещание по планированию спринта рассчитано на восемь часов для месячного спринта. Для более коротких спринтов событие пропорционально короче. Например, двухнедельные спринты имеют четырехчасовые встречи по планированию спринтов.

Это обычно работает для меня.

Пока это нужно, не меньше и не больше. Все остальное не Agile.

Если у вас есть команда из 2–3 разработчиков, и вы выполняете спринты в течение 1 недели, то более часа, вероятно, будут контрпродуктивными.

Если у вас есть команда из 15 человек и двухнедельных спринтов, на которые вы смотрите весь день, ничего менее подробного недостаточно.

Требуется опыт, чтобы понять его в основном правильно, и именно для этого нужны ретроспективы, команда решает, что будет слишком длинным или слишком коротким.

Не беспокойтесь о том, чтобы довести его до совершенства или придерживаться того, что говорится в какой-то книге, попробуйте что-нибудь и доработайте.

SCRUM - это улучшение процесса в итерациях так же, как и улучшение вашего кода в итерациях.

Не формируйте свой бизнес вокруг процесса. Процесс поддерживает ваш бизнес. В тот момент, когда вы делаете процесс сам по себе, пришло время для процесса получить топор. Для этого не существует «правильного» пути. Встречи должны идти только до тех пор, пока вы что-то делаете в них. Если это займет у вас 30 минут или 4 часа, пока это работает, то продолжайте. Игнорируйте то, что говорит вам какая-то книга / блог / тренер, и делайте то, что подходит именно вам.

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

Из Scrum Primer ( PDF ):

Уточнение отставания по продукту

Одно из менее известных, но ценных руководств в Scrum заключается в том, что пять или десять процентов каждого Спринта должны быть выделены Командой для уточнения (или «подготовки») Отставания Продукта. Это включает в себя подробный анализ требований, разбиение крупных предметов на более мелкие, оценку новых предметов и переоценку существующих предметов. Скрам молчит о том, как выполняется эта работа, но часто используемая техника - это целенаправленный семинар в конце Спринта, так что команда и владелец продукта могут посвятить себя этой работе без перерыва. Для двухнедельного спринта, пять процентов продолжительности подразумевают, что на каждом спринте проводится полдня семинара по уточнению журнала ожидания продукта. Это уточнение не относится к элементам, выбранным для текущего спринта; это для предметов на будущее, скорее всего, в следующем один или два спринта. С этой практикой Sprint Planning становится относительно простым, потому что владелец продукта и команда Scrum начинают планирование с четкого, тщательно проанализированного и тщательно оцененного набора элементов. Признаком того, что этот семинар по доработке не проводится (или не выполняется хорошо), является то, что планирование спринта включает в себя важные вопросы, открытия или путаницу и кажется неполным; тогда планирование работы часто перетекает в сам спринт, что обычно нежелательно.

Это означает, что вы можете сосредоточиться на планировании во время планирования, и это не занимает целый день, и команда начинает терять фокус и скучать.

В Scrum при работе с 2-недельными спринтами планирование спринта ограничено по времени 4 часами, что делает его мероприятием на полдня. Одной из причин относительно большого количества времени является то, что команда разработчиков должна быть в состоянии уверенно договориться о том, что все элементы, включенные в список заданий спринта, могут быть доставлены, а это означает, что они должны знать детали. Нередко в рамках планирования спринта команды отрываются от пространства для собраний на периоды времени, чтобы дополнительно исследовать предметы и убедиться, что они «готовы» войти в очередь на спринт. (Это может помочь думать о планировании спринта как о событии, а не как о встрече.)

Используйте свое «Определение готовности» и промежуток времени, в течение которого событие планирования спринта позволяет гарантировать, что все элементы невыполненных работ, входящие в спринт, являются выполнимыми и готовыми . то есть они могут быть выполнены (полностью, в соответствии с «Определением выполненного») в рамках спринта, и у команды достаточно информации, чтобы сделать это прямо сейчас.
Обратите внимание, что вы, вероятно, не хотите делать это для ВСЕХ предметов во время планирования спринта, так как это может занять очень много времени. Старайтесь регулярно проводить очистку журнала невыполненных работ (вне планирования спринта), где вы можете разбить элементы журнала невыполненных работ и оценить объекты, которые еще не были оценены, например, с помощью планирования покера. (Я обнаружил, что это может быть эффективным занятием для рабочего ужина с командой разработчиков, если вы можете позволить себе роскошь присутствия вашей команды во время обеда!)

Тем не менее, высокоприоритетные элементы часто могут быть добавлены в портфель продукта владельцем продукта непосредственно перед планированием спринта, и хотя обычная обработка журнала ожидания может и обычно должна выполняться до события планирования спринта, всегда будут новые элементы, подобные этому, где команде нужно потратить время на проработку деталей и оценку сложности во время мероприятия по планированию спринта, поэтому оно может растянуться до 4 часов в спринте на 10 дней / 2 недели.

Если вам нужно затянуть более длительные обсуждения этого события, то в журнале спринтов может быть элемент отставания, чтобы «иметь такое и такое обсуждение, чтобы установить x», но вам следует избегать включения элементов спринта, чтобы делать то, что вы собираетесь определить потребности, сделанные в ходе этого обсуждения, так как они не являются «готовыми» элементами журнала невыполненных работ для спринта.

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

На совещании по планированию спринта команда должна определить два набора вещей:

А) Что будет разработано командой во время этого спринта?

Б) Как это будет развиваться

Это собрание должно быть ограничено по времени, до двух часов на каждую неделю Спринта, равномерно распределено для каждой части (часть A и часть B) встречи.

Таким образом, для Спринта продолжительностью 4 недели эта встреча должна быть не более 8 часов, до 4 часов для части A и до 4 часов для части B.

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

В части B команда разработчиков обсудит, как разрабатывать более сложные пользовательские истории, уже выбранные для разработки. Скорее всего, у команды разработчиков не будет достаточно времени, чтобы обсудить, как разработать все выбранные пользовательские истории, поэтому команда должна выбрать самые сложные пользовательские истории.

Во время спринта у команды разработчиков достаточно времени для завершения этого обсуждения.

Согласно Scrum Guide :

Scrum События

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