Наши встречи по планированию спринтов не только не веселые, но и ужасные.

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

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

Как мы можем сделать встречи более приятными?

...

Еще несколько деталей, в ответ на запросы о дополнительной информации:

Почему элементы отставания не вставляются и не расставляются по приоритетам до начала спринта?

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

Почему разработчики жалуются?

1. Встречи длинные.

2. Встречи однообразные. История за историей, задача за задачей, изо всех сил (да, изо всех сил), чтобы оценить, сколько времени это займет и что это включает.

3. Оценка задач делает оценку истории пользователя бессмысленной.

4. Чем дольше встреча, тем меньше внимания в комнате. Чем менее сосредоточены коллеги, тем дольше длится встреча. Развивается рекурсивная спираль ненависти. Мы решили разделить встречу на два дня, чтобы люди были сосредоточены, но разработчики об этом не слышали. Один день планирования достаточно плох; теперь у нас будет два ?!

Часть нашей проблемы заключается в том, что мы углубляемся в очень мелкие детали (чтобы получить более точные оценки). Но когда мы приблизительно оцениваем, мы идем далеко от цели!

Подводя итоги вопроса:

• Что мы делаем не так?

• Какие есть дополнительные способы сделать встречу в целом более приятной?

Сделать оценку проще

Сломайте планирование спринта.

Вам нужно оценить отдельные задачи? Я сделал планирование спринта двумя способами:

1. Истории оцениваются в баллах, а затем задачи оцениваются в часах.
2. Истории оцениваются в баллах, а задачи просто не поддаются оценке.

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

Делая это, вы можете сократить время, которое вы тратите на планирование спринта . Истории оцениваются во время планирования спринта, и когда вы начинаете спринт, вы можете записать все задачи, которые вы можете придумать, которые составляют эту историю. Очевидно , что если есть моменты , которые вы столкнетесь при оценке истории , которую вы знаете , должны быть рассмотрены в задаче, можно добавить , что на информацию рассказа и поставить его в качестве задачи.

Смета в идеальных единицах

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

Под этим я подразумеваю то, что после некоторого времени, оценивая их в идеальные дни, вы понимаете, что, возможно, для завершения рассказа вам понадобится дополнительно 25% времени, которое вы оцениваете в среднем. Допустим, вы оценили 4 идеальных рабочих дня, а вместо этого у вас ушло 5. Со временем вы отслеживаете это, а затем у вас есть приблизительное представление о преобразовании из идеальных дней в реальные дни. Ваш первый инстинкт должен был бы попытаться компенсировать это чрезмерной оценкой, и вы, вероятно, ошиблись. Главное здесь - оставаться последовательным. Таким образом, ваш долгосрочный средний показатель остается прежним. Конечно, иногда это будет ниже, а иногда и закончится, но чем больше вы оцениваете, тем лучше для вас. Если вы обнаружите, что вы все еще не может получить приличную оценку, может быть, это означает, что вы недостаточно знаете историю, чтобы правильно ее оценить.

Поговорим об истории

Когда вы оцениваете, у каждого должно быть четкое представление о том, что нужно будет сделать, от начала до конца, и что потребуется для завершения этой истории. Вам не нужно знать каждую деталь, но достаточно, чтобы вы думали, что вы сами взялись за историю. Если у вас нет такого уровня уверенности, вам, вероятно, не стоит его оценивать. Если вы говорите: «Ну, эта история слишком велика, чтобы мы могли знать большинство деталей», то это говорит о том, что история слишком большая и ее следует разбить. Истории, по крайней мере, по моему опыту, были настолько малы, что один человек, в случае необходимости, мог бы поработать над этим в одиночку и выполнить его в течение недели или двух.

Это также поможет решить Ваш второй пункт в редактировании, который является слишком большой оценкой . Вместо того, чтобы оценивать каждую задачу для каждой отдельной истории, вы просто оцениваете историю в целом, что должно помочь удалить большую часть оценки. Что касается того, чтобы сделать встречи менее монотонными, я бы предложил планирование покера, о котором вы можете узнать больше информации выше.

Сделайте планирование более интересным

Оцените с помощью Planning Poker

Что касается того, чтобы сделать оценку более увлекательной, вы пробовали планировать покер ? Это способ, которым я всегда планировал все свои спринты в нескольких командах, и это хороший способ привлечь всех к участию, так как каждый должен хотя бы выбрать ЧТО-ТО. Также достаточно веселья, когда все в команде выбирают 3, а кто-то ставит 20 и должен объясниться, или когда все в команде ставят 5, а менеджер ставит 8 (кто будет спорить с босс, когда он хочет дать вам больше времени!).

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

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

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

2. Почему уходит один день, чтобы разбить вещи на задачи? Если у вас достаточно разумная команда (2-4 разработчика, 0,5-1,5 QA на одного разработчика, 1-2 разные), у вас должно быть 2-4 пользовательских истории этого спринта. Потратьте 30 минут или около того, чтобы владелец продукта уточнил требования, а затем около 30 минут, разбив его на ~ 8 часов. Не вводите задачи во время встречи. Просто согласитесь, как команда, что задач достаточно, чтобы здравомыслящие люди поняли их, кто за них отвечает, и сколько времени они должны выполнять. Согласитесь, что «сколько времени они должны занять (включая тестирование)» удобно вписывается в спринт.

3. Если это не просто разбить вещи на задачи, что еще вы делаете? Конечно, ретроспектива может занять 30-60 минут, но будет короче, когда команды попадут в канавку.

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

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

Некоторые удачные идеи, которые я лично испробовал или услышал от других команд:

• Создание пользовательских историй и расстановка приоритетов без всей команды. Владелец продукта и / или Scrum Master может справиться с большой занятой работой и просто позволить команде настроить ее.
• Сделайте свое отставание значительно длиннее, чем один спринт. На его создание может потребоваться некоторое время, но если ваше отставание достаточно велико, совещания по планированию сводятся к небольшим изменениям или рассмотрению последних событий в бизнесе.
• Проводите встречи по оценке отдельно от планирования спринта. Если люди думают, что собрания слишком длинные, нет причин не разделять их.
• Конкретно план врывается в повестку дня. Это полезно, если вы часто тратите время на ожидание возвращения одного или двух членов команды.
• Перерыв в середине собрания и поручите всем задавать одну или две пользовательские истории, а затем собраться вместе, чтобы сообщить и получить консенсус.
• Убедитесь, что ваше совещание по планированию посвящено тому, что делать, а не как это делать. Инженеры очень легко попадают в последнее. Если вам нужно, организуйте отдельные встречи дизайнеров, где вы будете обсуждать, как это сделать.
• Разделите свои истории на исследование и реализацию. Планирование собраний часто длится слишком долго, когда члены команды слишком мало знают о том, над чем они будут работать, и пытаются выяснить это во время собрания.
  Например, скажем, вам нужно интегрироваться с API, с которым ваша команда не имеет опыта работы. Вместо того, чтобы пытаться создавать оценки и задачи на совещании по планированию о чем-то, о чем вы ничего не понимаете, сделайте одну историю исследований, чтобы изучить API, создайте простое приложение "hello world" и обучите его команде. Тогда вы будете готовы планировать реальную работу.
• Отслеживайте во время ваших встреч конкретные вопросы. Не просто «планирование скучно», а уровень детализации вроде «мы тратим много времени на разговоры о неясных требованиях, и никто, кажется, не знает правильного ответа». Затем обсудите эти конкретные проблемы в своих ретроспективах и проведите мозговой штурм для конкретных решений. Разбейте свою проблему, пока части не будут легки решить.

Мы проводим планирование спринта и ретроспективу одновременно, и почти всегда выполняем их за 90 минут, но мы являемся одной из самых быстрых команд. Мы проводим долгосрочное планирование для всей компании каждые 5 спринтов, что занимает 4-6 часов. Конечно, каждая команда уникальна, но если вы проводите целый день в каждом спринте, есть много возможностей для совершенствования.

Ваши сессии планирования слишком длинны!

Исходя из моего опыта, планирование спринта должно занимать не более 2 часов в неделю (например, 2-недельный спринт должен занимать не более 1/2 дня), но успешные должны быть короче (половина).

В вашем конкретном случае: почему вы оцениваете задачи? Вы должны оценивать только истории во время планирования. Задачи могут быть оценены позже владельцами конкретных задач .

Способ, который работал для меня:

• Быстрое введение в спринт от ПО
• Оценка спринтерской способности
• Истории заканчиваются и планируют покер (время составляет 5/10 минут на историю), пока не будет достаточно материала для покрытия спринта
• Официальное обязательство / прогноз команды

Затем, параллельно / пар / самоорганизация на наших рабочих столах, постановка задач и оценка задач.

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

• Ретроспектива. Мы начали делать это во второй половине дня последнего дня, но мы часто возвращались к спринту, а затем возвращались к работе, связывая последние свободные концы работы этого спринта, поэтому мы решили, что было бы лучше убедиться, что работа была позади нас, прежде чем вернуться к ней. Также казалось логичным объединить все накладные расходы на процесс Scrum, чтобы другие дни можно было планировать и проводить в более идеальных условиях. Обычно это занимает 2 часа.
• Спринт Планирование. Задержка была оценена во время совещания по планированию вехи (которое может составлять целый день как для разработчиков, так и для ПО), и было определено приоритетом для ПО до начала каждого спринта. Мы выяснили, сколько дней разработчиков у нас было в наличии (с учетом праздников, отпусков и т. Д.), Собрали работу, которую, как нам казалось, мы могли бы выполнить, с нуля, и быстро проанализировали требования пользователей (ранее проверенные нашими БА), чтобы получить более полное представление о том, что влечет за собой работа, чем мы получили с помощью простого обзора во время MPM. Обычно это занимает еще 2 часа.
• Планирование задач. Зная истории и критерии приемлемости, мы разбили каждую историю на задачи размером с укус, оцененные в идеальных часах (час, посвященный исключительно выполнению этой задачи без отвлекающих факторов и препятствий). То, как наша шкала баллов была откалибрована, 5 - это спринт разработчика, поэтому 1 может быть чем угодно, включая два дня разработчиков. По этой причине практически все должно было быть разбито, чтобы члены команды могли показать прогресс на доске. Это был еще один 2-часовой блок, с некоторыми компромиссами между этим и следующим пунктом.
• AAT Изложение. Наши ПО и БА не были программистами и не кодировали. ОО скрывались за контрактом, предусматривающим, что они будут предоставлять требования в форме шаблона Word и будут работать с БА, чтобы уточнить их в этой форме. БА понимали код, но их время было чисто анализом и окончательным тестированием (что требовало существования системы, чтобы они могли записывать свои макросы в Selenium). Таким образом, чтобы убедиться, что наш код будет соответствовать критериям приемлемости, когда мы дошли до этого, мы должны были написать наши собственные AAT, моделирующие действия «бумажного» приемочного теста. Обычно мы делали это в той же платформе NUnit, которую использовали для модульных и интеграционных тестов (мы пробовали FitNesse и не могли отказаться от него достаточно быстро). Это был остаток нашего первого дня каждого спринта и продолжался во второй.

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

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

Конкретно решая ваши проблемы:

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

• Встречи однообразные - некоторые из них будут; вы работаете по кусочкам размера укуса, по одному, так что вы будете делать одно и то же снова и снова. Сосредоточение команды и стремление к достижению цели встречи помогут.

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

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

  Если все ваши истории занимают один день или меньше, то это излишне, но не все шкалы баллов калибруются одинаково; на моей последней работе 5 было две недели разработчиков (потому что в начале у нас было много эпических оценок), что в линейном масштабе показывало что-то до двух дней разработчиков. Учитывая такой масштаб, практически все должно быть разбито на задачи. В моей новой компании точка ближе к половине дня для разработчика, поэтому 1 или даже 2 - это, безусловно, ее собственная задача, а 3-8 неясны в отношении того, чтобы заставить команду разделить ее на задачи.

• Это порочный круг, который занимает больше времени, делая людей менее сосредоточенными, поэтому это занимает больше времени - Time-box your time-box. Делайте перерывы, как и при кодировании. Каждые 30 минут тратят 5 минут на разминку, перегруппировку и т. Д. Вы можете делать это каждые десять минут каждый час, но не тяните слишком много времени на встречи. Ваши парни могут проголодаться, или вам нужно больше кофе, или перерыв в ванной и т. Д. Не отрицайте их; если вы заставите их смириться с этим, вы обнаружите, что их мысли блуждают. Кроме того, поддержание коротких, приятных обсуждений также поможет, как упоминалось ранее.

Встреча по планированию спринта состоит из 2 частей:

1. Решите, что будет делать команда
2. Решите, как команда это сделает.

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

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

Это действительно так. Если встречи по дизайну не веселые, то просто что-то не так.

Да, я знаю, что это старый вопрос, но у меня есть новый ответ. :П

Разделите встречу.

Мы разделили нашу встречу по планированию Sprint на 3 отдельные мини-встречи

• Отставание груминг
• Выбор истории
• Распределение задач

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

Так что да, мы потерпели неудачу в планировании: -O

Я расскажу более подробно о том, что происходит в каждой сессии через секунду, но позвольте мне объяснить, как мы к этому пришли.

У нас, как и у вас, была проблема с действительно ужасными встречами по планированию Sprint. У нас были все правильные элементы, но все просто ушло навсегда и действительно истощало умственно и эмоционально, чтобы пройти.

Затем у меня появилась идея после прочтения статьи Business Insider на 5-минутной ежедневной конференции Pivotal о том, как разбивать наши собрания на более короткие сессии и выполнять их в начале каждого дня.

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

Поэтому мы решили попробовать это.
Мы разбили нашу 2-часовую встречу на три 25-минутных сеанса. (да, это нечеткая математика, но все чувствовали, что наши встречи были слишком длинными, и хотели сделать это только в том случае, если мы сэкономили время).

И это сработало! Мы занимаемся этим уже около 6 недель на двух отдельных проектах (всего 6 двухнедельных спринтов), и это имеет огромное значение.
Мы более продуктивны. Мы экономим кучу времени.
Мы получаем лучшие результаты. И мы больше не боимся наших совещаний по планированию.

И, честно говоря, наш 25-минутный интервал времени довольно свободный - некоторые сеансы идут очень быстро, например, 5-10 минут на некоторые из наших сеансов груминга, а некоторые идут долго, например, когда мы заканчиваем тем, что идентифицируем новые истории или вынуждены разбивать истории и переоценить во время переговоров. В целом, обычно он составляет в среднем не более 1,5 часов для всего шебанга, и я думаю, именно поэтому он работает так хорошо.

На деталях .....

Отставание груминг

Довольно просто - мы просматриваем первоочередные истории, рассказываем о том, что они влекут за собой, и проверяем, что наши оценки хороши

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

Кроме того, если ПО добавило какие-либо новые истории, которые он считает высокоприоритетными, это время, чтобы оценить их.

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

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

Выбор истории

Наденьте своего Криса Восса , пора договариваться.

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

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

Задачи

Итак, я буду первым, кто скажет, что задачи были моей НАИМЕНЕШНОЙ любимой частью планирования на наших старых однодневных встречах.

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

Но теперь, определяя DoD в один день и не выполняя задачи до следующего, мы не утомляемся, мы всегда в правильном состоянии ума, и это дает нам целый день, чтобы мариноваться над историей и действительно продумайте и поймите все задачи, прежде чем мы начнем.

Это само по себе, ИМХО, полностью меняет игру.

Собираем все вместе.

Итак, вот как выглядит наше расписание церемонии Sprint:

• Понедельник - Ежедневные схватки -> Обзор спринта
• Вторник - Ежедневные схватки -> Отставание по грумингу
• Среда - Ежедневная схватка -> Выбор истории
• Четверг - Ежедневная схватка -> Задачи
• Пятница - Ежедневные схватки -> Ретроспектива

Это сработало очень хорошо для нас. Если вы попробуете, я бы хотел услышать, что вы думаете.

У нас еженедельный спринт с часовым собранием, на котором мы обсуждаем предыдущий спринт, что еще предстоит сделать, а затем переходим к планированию предстоящей недели. Все в течение часа.

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

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

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

Дайте власть команде. То есть заставить их работать над вещами, которые они считают наиболее важными.