Планирование спринта — это событие в Scrum, где команда определяет объем работы на предстоящий спринт и способы её выполнения. В отличие от традиционного планирования проектов, здесь команда сама выбирает задачи и оценивает свои возможности на короткий период.
Планирование спринта — это событие в Scrum, где команда определяет объем работы на предстоящий спринт и способы её выполнения. В отличие от традиционного планирования проектов, здесь команда сама выбирает задачи и оценивает свои возможности на короткий период.
Планирование спринта напоминает еженедельное совещание отдела, где руководитель не раздает задания сверху, а команда сама изучает приоритеты и решает, что реально успеть за неделю. Каждый участник понимает общую цель и может честно оценить свои возможности.
Во-первых, команда самостоятельно выбирает задачи из бэклога продукта, основываясь на своих возможностях и опыте. Раньше менеджеры часто перегружали разработчиков нереалистичными планами, что приводило к авралам и низкому качеству. Особенно это характерно для организаций, привыкших к постоянному контролю. Теперь команда может сказать: “Мы возьмем эти пять задач, потому что знаем свою скорость работы”.
Во-вторых, участники детально обсуждают техническое решение каждой задачи прямо на планировании. Если раньше разработчики получали задачи без контекста и тратили время на выяснение деталей, то теперь все вопросы решаются сразу. Команда понимает не только что делать, но и как это делать.
Команда мобильного приложения для доставки еды проводит планирование двухнедельного спринта. Владелец продукта показывает приоритетные задачи: новый экран оплаты, исправление бага с уведомлениями и интеграция с новым поставщиком. Разработчики изучают каждую задачу, задают вопросы о деталях интеграции, обсуждают сложности с дизайном экрана оплаты. Тестировщик уточняет критерии приемки для каждой функции. В итоге команда берет задачи на 26 story points, зная, что их средняя скорость — 28 points за спринт, но учитывая отпуск одного разработчика.
Некоторые команды превращают планирование в формальность, где менеджер просто распределяет задачи по участникам. Такой подход убивает главную идею — командное обязательство и коллективную ответственность за результат. Другие команды тратят слишком много времени на детальное планирование каждой мелочи, забывая, что спринт длится всего две недели и многие детали можно уточнить по ходу работы. Третья проблема — игнорирование исторических данных о скорости команды, что приводит к постоянному невыполнению планов.
Качественное планирование спринта создает общее понимание целей и способов их достижения у всех участников команды, что особенно важно для проведения эффективных agile встреч. Когда разработчик, тестировщик и аналитик вместе обсуждают техническое решение, они предотвращают множество проблем на этапе реализации. Планирование также помогает владельцу продукта понять реальные возможности команды и корректировать ожидания заинтересованных сторон, основываясь на фактах, а не на желаниях.
Сначала слушаем, задаём вопросы, разбираемся в ситуации. Потом предлагаем подход и только тогда обсуждаем условия.