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

Кто-то спросит, а в чем проблема? Представьте себе, что команда пришла на встречу по планированию двух-недельной итерации:

• Сначала они решают оценить сложность требований и для этого садятся играть в Planning Poker. Даже если процесс хорошо модерируется, и вы даете по всего лишь 2 минуты, чтобы обсудить каждый элемент Бэклога, то все равно могут встретиться требования, которые не понятны и нельзя оценить, или на ходу получить ответ от Владельца Продукта.
• Потом Владельцу Продукта необходимо обновить приоритеты, поскольку получив информацию о сложности реализации, он может поменять свое первоначальное мнение. Что интересно, команда в это время может даже сидеть без дела, поскольку они не всегда участвуют в процессе принятия решений о приоритетах.
• Потом команда начинает выбирать истории сверху Бэклога и спрашивать себя: “Мы сможем это сделать в течение Спринта?”. При этом может выясниться, что для того, чтобы начать делать именно это требование не хватает данных, или технических знаний, или команда не сможет сделать подряд несколько больших и сложных элементов, или еще что-то в этом роде.
• Ну и после того, как выбраны элементы “на глазок” (т.е. хотя бы ограничиваясь средней скоростью) – наконец-то, команда приступает к планированию Спринта и делит требования на задачи, уточняет оценку и т.п.

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

Как лечить?

Совет прост – разделите одну большую встречу (по сути, с разными темами) на несколько коротких и сфокусированных на одной теме.

Для этого вам нужна всего лишь еще одна “недокументированная встреча”, которая может быть ограничена 30 минутами или максимум часом. Цель этой встречи – оценить новые требования, а заодно и отфильтровать те, которые не понятны или не могут быть сделаны по какой-то причине (плохо написаны, не хватает данных для оценки, зависит от внешнего подрядчика (который не готов), у вас нет экспертизы и т.п. и т.д.). Если вы играете в Planning Poker, то эта встреча как раз для этого, и вы можете максимально абстрагироваться от технических деталей, поскольку никто не знает, будет ли это требование в следующей итерации или вообще уйдет в корзину. Поверьте опыту, это позволяет избежать ненужных дискуссий от особо дотошных разработчиков, а на точность оценки никак не влияет :-).

Называть такую встречу можно как угодно, я встречал разные варианты: “Оценочная встреча” (Estimation meeting), а еще чаще Backlog Grooming (как перевести не знаю 🙂 ).

Итак, еще раз. Инвестируя около часа командного времени раз в две недели, вы можете:

• Оценить новые требования
• Разбить большие и сложные требования на более мелкие
• Отфильтровать непонятные или неполные требования
• Добавить критерии приемки, чтобы было понятно, когда остановиться
• Заметить связи между требованиями и, возможно, учесть архитектурные решения

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

Хорошая инвестиция, не так ли? 🙂