Как долго должна длиться встреча по планированию спринта?
16
По вашему опыту, как долго должна длиться встреча по планированию спринта (Scrum)? 8 часов? Или это должно быть короче (лаконично), и дальнейшие обсуждения должны быть запланированы как часть спринта? Наши спринты 10 дней.
8 часов в 10-дневном спринте определенно звучат для меня слишком много. Дискуссии, которые не требуют всей команды, должны проводиться в отдельных сессиях, только для вовлеченных членов.
Петер Тёрёк
1
Таким образом, вы планируете другие встречи, а не обсуждаете все в планировании. Точка отмечена.
wleao
Следует обсудить предстоящие идеи и планы, чтобы у большинства членов команды было общее и общее понимание о них. Критерий таков: во время совещания по планированию никто не должен удивляться, услышав что-то в первый раз. Всякий раз, когда происходит такой «сюрприз», корректируйте, увеличивая объем общения, который происходит перед следующим совещанием по планированию. (Исключениями являются действительно новаторские объявления, поступающие от владельцев проектов.)
Совещание по планированию спринта рассчитано на восемь часов для месячного спринта. Для более коротких спринтов событие пропорционально короче. Например, двухнедельные спринты имеют четырехчасовые встречи по планированию спринтов.
Это, вероятно, хорошая отправная точка, но следует также отметить, что вам необходимо адаптировать процесс к вашему проекту, команде и организации, чтобы он работал на вас. То, что другим людям повезло с этим, не означает, что оно будет работать для вас прямо из коробки.
Томас Оуэнс
6
Однако, если вы собираетесь попробовать Scrum, вам, вероятно, следует сначала попробовать его на основе определенных рекомендаций. Затем, если что-то не работает, уточните это. Если вы измените правила еще до того, как начнете, вы проигнорируете эмпирические данные, которые заставили людей, которые разработали Scrum, рекомендовать то, что они рекомендовали, - без каких-либо эмпирических данных, свидетельствующих о том, что это неправильно для вас.
Мэтью Флинн
@MatthewFlynn хороший момент
HA
В моей команде из 3 человек, как правило, имели только получасовые спринты, а когда команде было 7, обычно это был только час для двухнедельных спринтов.
Зимус
27
Пока это нужно, не меньше и не больше. Все остальное не Agile.
Если у вас есть команда из 2–3 разработчиков, и вы выполняете спринты в течение 1 недели, то более часа, вероятно, будут контрпродуктивными.
Если у вас есть команда из 15 человек и двухнедельных спринтов, на которые вы смотрите весь день, ничего менее подробного недостаточно.
Требуется опыт, чтобы понять его в основном правильно, и именно для этого нужны ретроспективы, команда решает, что будет слишком длинным или слишком коротким.
Не беспокойтесь о том, чтобы довести его до совершенства или придерживаться того, что говорится в какой-то книге, попробуйте что-нибудь и доработайте.
SCRUM - это улучшение процесса в итерациях так же, как и улучшение вашего кода в итерациях.
Час кажется немного коротким для 3 разработчиков / спринтов на 1 неделю. С другой стороны, я только что закончил относительно небольшой проект, в котором мы делали 5-минутное планирование еженедельных спринтов. Это зависит от проекта и от карт, потому что иногда требуется больше (или меньше) обсуждения при планировании спринта.
конфигуратор
2
Одна из ключевых идей Scrum, как Agile-фреймворка, заключается в том, что вы выполняете <i> временные рамки </ i>, такие как спринт, встреча по планированию спринта и ежедневные занятия спортом / схватка. Дело в том, чтобы держать вещи в фокусе. Time-boxing не означает, что вы не можете занять меньше времени, чем указано. Только то, что вы не должны брать больше, так как это приводит к тому, что люди теряют фокус, а также уменьшает количество времени, которое команда должна выполнять.
Мэтью Флинн
7
Не формируйте свой бизнес вокруг процесса. Процесс поддерживает ваш бизнес. В тот момент, когда вы делаете процесс сам по себе, пришло время для процесса получить топор. Для этого не существует «правильного» пути. Встречи должны идти только до тех пор, пока вы что-то делаете в них. Если это займет у вас 30 минут или 4 часа, пока это работает, то продолжайте. Игнорируйте то, что говорит вам какая-то книга / блог / тренер, и делайте то, что подходит именно вам.
Почему бы не начать процесс, как задумано, и адаптироваться оттуда? Если вы решили использовать гибкие методы и не изменили свой бизнес в этом направлении, у вас уже есть проблемы.
JeffO
3
Потратьте столько времени, сколько вам нужно, чтобы вы выбрали достаточно, чтобы ваша команда думала, что они могут разумно добиться успеха в спринте. Но вы должны тратить время во время (предыдущего) спринта на уточнение отставания: оценку и уточнение историй.
Одно из менее известных, но ценных руководств в Scrum заключается в том, что пять или десять процентов каждого Спринта должны быть выделены Командой для уточнения (или «подготовки») Отставания Продукта. Это включает в себя подробный анализ требований, разбиение крупных предметов на более мелкие, оценку новых предметов и переоценку существующих предметов. Скрам молчит о том, как выполняется эта работа, но часто используемая техника - это целенаправленный семинар в конце Спринта, так что команда и владелец продукта могут посвятить себя этой работе без перерыва. Для двухнедельного спринта, пять процентов продолжительности подразумевают, что на каждом спринте проводится полдня семинара по уточнению журнала ожидания продукта. Это уточнение не относится к элементам, выбранным для текущего спринта; это для предметов на будущее, скорее всего, в следующем один или два спринта. С этой практикой Sprint Planning становится относительно простым, потому что владелец продукта и команда Scrum начинают планирование с четкого, тщательно проанализированного и тщательно оцененного набора элементов. Признаком того, что этот семинар по доработке не проводится (или не выполняется хорошо), является то, что планирование спринта включает в себя важные вопросы, открытия или путаницу и кажется неполным; тогда планирование работы часто перетекает в сам спринт, что обычно нежелательно.
Это означает, что вы можете сосредоточиться на планировании во время планирования, и это не занимает целый день, и команда начинает терять фокус и скучать.
@GottliebNotschnabel: Спасибо, это новое. Я переключил ссылку на один, не требующий входа в систему.
Хьюго
2
В Scrum при работе с 2-недельными спринтами планирование спринта ограничено по времени 4 часами, что делает его мероприятием на полдня. Одной из причин относительно большого количества времени является то, что команда разработчиков должна быть в состоянии уверенно договориться о том, что все элементы, включенные в список заданий спринта, могут быть доставлены, а это означает, что они должны знать детали. Нередко в рамках планирования спринта команды отрываются от пространства для собраний на периоды времени, чтобы дополнительно исследовать предметы и убедиться, что они «готовы» войти в очередь на спринт. (Это может помочь думать о планировании спринта как о событии, а не как о встрече.)
Используйте свое «Определение готовности» и промежуток времени, в течение которого событие планирования спринта позволяет гарантировать, что все элементы невыполненных работ, входящие в спринт, являются выполнимыми и готовыми . то есть они могут быть выполнены (полностью, в соответствии с «Определением выполненного») в рамках спринта, и у команды достаточно информации, чтобы сделать это прямо сейчас.
Обратите внимание, что вы, вероятно, не хотите делать это для ВСЕХ предметов во время планирования спринта, так как это может занять очень много времени. Старайтесь регулярно проводить очистку журнала невыполненных работ (вне планирования спринта), где вы можете разбить элементы журнала невыполненных работ и оценить объекты, которые еще не были оценены, например, с помощью планирования покера. (Я обнаружил, что это может быть эффективным занятием для рабочего ужина с командой разработчиков, если вы можете позволить себе роскошь присутствия вашей команды во время обеда!)
Тем не менее, высокоприоритетные элементы часто могут быть добавлены в портфель продукта владельцем продукта непосредственно перед планированием спринта, и хотя обычная обработка журнала ожидания может и обычно должна выполняться до события планирования спринта, всегда будут новые элементы, подобные этому, где команде нужно потратить время на проработку деталей и оценку сложности во время мероприятия по планированию спринта, поэтому оно может растянуться до 4 часов в спринте на 10 дней / 2 недели.
Если вам нужно затянуть более длительные обсуждения этого события, то в журнале спринтов может быть элемент отставания, чтобы «иметь такое и такое обсуждение, чтобы установить x», но вам следует избегать включения элементов спринта, чтобы делать то, что вы собираетесь определить потребности, сделанные в ходе этого обсуждения, так как они не являются «готовыми» элементами журнала невыполненных работ для спринта.
Как уже говорили люди, есть причины, по которым вы можете захотеть изменить способ запуска Scrum, если этот процесс не работает эффективно для вас. Скрам, однако, очень хорошо продуманный и проверенный фреймворк для начала, поэтому я хотел бы убедиться, что ваши рассуждения оправданы, прежде чем менять процесс.
На совещании по планированию спринта команда должна определить два набора вещей:
А) Что будет разработано командой во время этого спринта?
Б) Как это будет развиваться
Это собрание должно быть ограничено по времени, до двух часов на каждую неделю Спринта, равномерно распределено для каждой части (часть A и часть B) встречи.
Таким образом, для Спринта продолжительностью 4 недели эта встреча должна быть не более 8 часов, до 4 часов для части A и до 4 часов для части B.
Во время части A команда разработчиков должна оценить скорость команды, которая, по их мнению, будет у них во время этого спринта. Они также должны оценить наиболее приоритетные пользовательские истории и выбрать достаточное количество этих (уже оцененных) пользовательских историй, чтобы они соответствовали их собственной предполагаемой скорости работы команды.
В части B команда разработчиков обсудит, как разрабатывать более сложные пользовательские истории, уже выбранные для разработки. Скорее всего, у команды разработчиков не будет достаточно времени, чтобы обсудить, как разработать все выбранные пользовательские истории, поэтому команда должна выбрать самые сложные пользовательские истории.
Во время спринта у команды разработчиков достаточно времени для завершения этого обсуждения.
Предписанные события используются в Scrum для создания регулярности и минимизации необходимости встреч, не определенных в Scrum. Все события являются событиями с временными рамками, так что каждое событие имеет максимальную продолжительность. Как только начинается Спринт, его продолжительность фиксируется и не может быть сокращена или удлинена. Остальные события могут заканчиваться всякий раз, когда цель события достигнута, обеспечивая необходимое количество времени, не теряя при этом процесса.
Ответы:
Согласно Scrum Guide :
Это обычно работает для меня.
источник
Пока это нужно, не меньше и не больше. Все остальное не Agile.
Если у вас есть команда из 2–3 разработчиков, и вы выполняете спринты в течение 1 недели, то более часа, вероятно, будут контрпродуктивными.
Если у вас есть команда из 15 человек и двухнедельных спринтов, на которые вы смотрите весь день, ничего менее подробного недостаточно.
Требуется опыт, чтобы понять его в основном правильно, и именно для этого нужны ретроспективы, команда решает, что будет слишком длинным или слишком коротким.
Не беспокойтесь о том, чтобы довести его до совершенства или придерживаться того, что говорится в какой-то книге, попробуйте что-нибудь и доработайте.
SCRUM - это улучшение процесса в итерациях так же, как и улучшение вашего кода в итерациях.
источник
Не формируйте свой бизнес вокруг процесса. Процесс поддерживает ваш бизнес. В тот момент, когда вы делаете процесс сам по себе, пришло время для процесса получить топор. Для этого не существует «правильного» пути. Встречи должны идти только до тех пор, пока вы что-то делаете в них. Если это займет у вас 30 минут или 4 часа, пока это работает, то продолжайте. Игнорируйте то, что говорит вам какая-то книга / блог / тренер, и делайте то, что подходит именно вам.
источник
Потратьте столько времени, сколько вам нужно, чтобы вы выбрали достаточно, чтобы ваша команда думала, что они могут разумно добиться успеха в спринте. Но вы должны тратить время во время (предыдущего) спринта на уточнение отставания: оценку и уточнение историй.
Из Scrum Primer ( PDF ):
Это означает, что вы можете сосредоточиться на планировании во время планирования, и это не занимает целый день, и команда начинает терять фокус и скучать.
источник
В Scrum при работе с 2-недельными спринтами планирование спринта ограничено по времени 4 часами, что делает его мероприятием на полдня. Одной из причин относительно большого количества времени является то, что команда разработчиков должна быть в состоянии уверенно договориться о том, что все элементы, включенные в список заданий спринта, могут быть доставлены, а это означает, что они должны знать детали. Нередко в рамках планирования спринта команды отрываются от пространства для собраний на периоды времени, чтобы дополнительно исследовать предметы и убедиться, что они «готовы» войти в очередь на спринт. (Это может помочь думать о планировании спринта как о событии, а не как о встрече.)
Используйте свое «Определение готовности» и промежуток времени, в течение которого событие планирования спринта позволяет гарантировать, что все элементы невыполненных работ, входящие в спринт, являются выполнимыми и готовыми . то есть они могут быть выполнены (полностью, в соответствии с «Определением выполненного») в рамках спринта, и у команды достаточно информации, чтобы сделать это прямо сейчас.
Обратите внимание, что вы, вероятно, не хотите делать это для ВСЕХ предметов во время планирования спринта, так как это может занять очень много времени. Старайтесь регулярно проводить очистку журнала невыполненных работ (вне планирования спринта), где вы можете разбить элементы журнала невыполненных работ и оценить объекты, которые еще не были оценены, например, с помощью планирования покера. (Я обнаружил, что это может быть эффективным занятием для рабочего ужина с командой разработчиков, если вы можете позволить себе роскошь присутствия вашей команды во время обеда!)
Тем не менее, высокоприоритетные элементы часто могут быть добавлены в портфель продукта владельцем продукта непосредственно перед планированием спринта, и хотя обычная обработка журнала ожидания может и обычно должна выполняться до события планирования спринта, всегда будут новые элементы, подобные этому, где команде нужно потратить время на проработку деталей и оценку сложности во время мероприятия по планированию спринта, поэтому оно может растянуться до 4 часов в спринте на 10 дней / 2 недели.
Если вам нужно затянуть более длительные обсуждения этого события, то в журнале спринтов может быть элемент отставания, чтобы «иметь такое и такое обсуждение, чтобы установить x», но вам следует избегать включения элементов спринта, чтобы делать то, что вы собираетесь определить потребности, сделанные в ходе этого обсуждения, так как они не являются «готовыми» элементами журнала невыполненных работ для спринта.
Как уже говорили люди, есть причины, по которым вы можете захотеть изменить способ запуска Scrum, если этот процесс не работает эффективно для вас. Скрам, однако, очень хорошо продуманный и проверенный фреймворк для начала, поэтому я хотел бы убедиться, что ваши рассуждения оправданы, прежде чем менять процесс.
источник
На совещании по планированию спринта команда должна определить два набора вещей:
А) Что будет разработано командой во время этого спринта?
Б) Как это будет развиваться
Это собрание должно быть ограничено по времени, до двух часов на каждую неделю Спринта, равномерно распределено для каждой части (часть A и часть B) встречи.
Таким образом, для Спринта продолжительностью 4 недели эта встреча должна быть не более 8 часов, до 4 часов для части A и до 4 часов для части B.
Во время части A команда разработчиков должна оценить скорость команды, которая, по их мнению, будет у них во время этого спринта. Они также должны оценить наиболее приоритетные пользовательские истории и выбрать достаточное количество этих (уже оцененных) пользовательских историй, чтобы они соответствовали их собственной предполагаемой скорости работы команды.
В части B команда разработчиков обсудит, как разрабатывать более сложные пользовательские истории, уже выбранные для разработки. Скорее всего, у команды разработчиков не будет достаточно времени, чтобы обсудить, как разработать все выбранные пользовательские истории, поэтому команда должна выбрать самые сложные пользовательские истории.
Во время спринта у команды разработчиков достаточно времени для завершения этого обсуждения.
источник
Согласно Scrum Guide :
источник