Планирование спринта в Scrum: как организовать собрания команды

Татьяна Минина

1
5 минут

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

Схема работы по модели Agile, источник https://www.scrum.org/agile-product-operating-model/
В рамках этого подхода сложные проекты разделяют на отдельные, легко достижимые этапы. После каждого команда должна представить готовую часть продукта, который потом могут быть доработаны или включены в итог.
Такой подход хорошо себя зарекомендовал в программировании, веб-дизайне, рекламе — там, где продукт внедряется итерациями, а требования могут измениться в ходе разработки. Он позволяет быстро адаптировать или дорабатывать продукт.
Также спринты снижают риски, которые может понести заказчик продукта. Например, этап длится две недели. Если заказчик понимает, что результат его не устраивает, его убытки составят расходы за две недели, а не весь бюджет на разработку продукта.
Как проходит планирование спринта: пошаговый процесс
В начале каждого спринта команда собирается на встречу, где определяются задачи (события), которые нужно выполнить за предстоящий период.
Scrum строится на четком распределении ответственности между тремя ключевыми ролями, которые участвуют в планировании и работе:
- Владелец продукта отвечает за его ценность, цель, а также управление бэклогом.
- Scrum-мастер выступает в роли руководителя и наставника команды.
- Разработчики — все члены команды, которые создают и реализуют продукт.
Встреча не должна быть слишком долгой — это непродуктивно. Планирование занимает до двух часов на каждую неделю спринта. Например, если у вас двухнедельные спринты, встреча может длиться не более четырех часов. Минимальное время не ограничено: если вы можете решить все вопросы за 15 минут — решайте и заканчивайте собрание.
Шаг 1. Определение приоритетов
Владелец продукта должен заполнить и скорректировать бэклог. Важно отметить, что уже сделано хорошо, что можно улучшить, какое направление является приоритетным для бизнеса. Так у команды будет вся информация о текущей ситуации.
Например, команда ведет продвижение в интернете нового продукта. Запущена рекламная кампания, увеличился поток лидов. Но клиент считает, что стоимость заявки из контекстной рекламы слишком высока, приоритет — ее снижение.
Шаг 2. Постановка цели
Здесь важно определить конкретные, измеримые цели спринта, а не просто составить список задач. Возможно, команда сможет придумать более креативные варианты достижения результата.
В примере выше бизнес и команда определяют цель: снизить CPL. Для этого нужно протестировать гипотезы, например:
- скорректировать таргетинги, чтобы охватывать более целевую аудиторию;
- проанализировать трафик и стоимость конверсии с разных площадок — какие-то отключить, а более выгодные, наоборот, масштабировать;
- запустить SEO-продвижение и контентный маркетинг: они обходятся дешевле платной рекламы, при этом снижают зависимость от нее и среднюю цену лида.
Шаг 3. Оценка объема работы
Когда сформирован пул задач, нужно определить, сколько ресурсов потребует выполнение каждой. Это можно оценить в человекочасах или в так называемых стори-пойнтах (условных единицах трудоемкости).
Первый способ привычнее для большинства. Стори-пойнты подойдут для заданий разного уровня сложности, глубины и неопределенности, которые исполнители не могут оценить в часах. Подробнее об оценке трудоемкости можно прочитать в статье «Как оценивать задачи по методу Planning Poker».
Например, запуск SEO-статьи можно оценить как три дня работы: сбор семантики, подготовка ТЗ, написание, публикация. Или как задачу со сложностью 2 по десятибалльной шкале, если тематика простая (например, куда поехать отдыхать летом). Но сложность может быть и 4, если тематика экспертная (к примеру, выбор фотообъектива для профессиональной съемки).
Шаг 4. Формирование плана
Крупные и долгосрочные задачи следует разделить на более мелкие, которые можно выполнить в рамках спринта. Из них формируется текущий бэклог, где указаны приоритеты, ответственные, ожидаемый результат. В примере выше ответственным за корректировку таргетингов станет специалист по контекстной рекламе, от него ожидают снижение цены лида на 5-10%.
В основе Scrum лежит эмпирический подход: план детализируется ровно настолько, чтобы отработать спринт. На следующей встрече он может быть продлен или скорректирован, исходя из практики. Например, корректировка таргетингов контекстной кампании не дала ожидаемый эффект. Зато неожиданно появился новый рекламный канал — Telegram Ads, который решили протестировать.
Шаг 5. Визуализация на канбан-доске
Бэклог удобно визуализировать на канбане или в подобном инструменте. Он удобен тем, что задачи можно переносить или видоизменять в соответствии с текущей ситуацией в проекте. Так каждому участнику команда легко видеть текущий статус, отслеживать прогресс, сохранять приоритеты. Подробнее о преимуществах инструмента можно прочитать в статье «Почему kanban-доски стали стандартом управления проектами».
Шаг 6. Подведение итогов и новое планирование
В конце спринта все статусы задач и промежуточные результаты опять надо актуализировать в бэклоге. После чего можно назначить новую встречу, чтобы наметить план на следующий спринт.
Обсуждение задач на собрании
Важно, чтобы вся команда участвовала в обсуждении и планировании. На практике встреча иногда сводится к тому, что разработчики по очереди отчитываются перед скрам-мастером как перед руководителем проекта, а владелец продукта говорит, что бы он еще хотел сделать. При таком подходе вовлеченность команды минимальна, для каждого главное — завершить задачу, а не создать ценность.
На самом деле это должно быть совместное обсуждение трех ключевых вопросов в зависимости от бизнеса:
- В чем ценность следующего спринта? То есть почему и над какой целью команда будет работать.
- Какие конкретные задачи будут сделаны? Это уже конкретные измеримые цели.
- Каким путем мы их решим? Здесь команда самостоятельно определяет, каким способом решать поставленные задачи.
Возьмем пример: команда работает над интернет-магазином клиента. В течение прошлых спринтов разработчики подготовили дизайн, контент, функционал, установили сайт на хостинг. Он уже представляет ценность для клиента. На новый спринт владелец продукта (сайта) задает цель «Настроить интеграции с платежными системами». Команда предлагает подходящие сервисы платежей, затем получает доступы к их API, разрабатывает и тестирует код для взаимодействия. Ценность сайта для клиента повышается, поскольку он стал функциональнее, привлекает больше покупателей.
О чем важно помнить на планировании спринта
- Четко доносите команде, какой результат ожидается от спринта и почему он важен.
- Разбивайте большие задачи на более мелкие и управляемые. Так можно разнести долгосрочное задание на несколько спринтов.
- Делайте приоритетом те задания, которые принесут наибольшую пользу продукту или бизнесу прямо сейчас.
- Слушайте команду: исполнители лучше понимают, сколько времени займет задача, какие могут быть сложности, как их решить. Хорошее планирование — это диалог, а не приказ.
- Не ставьте слишком много задач на спринт. Перегрузка ведет к выгоранию, снижению качества работы и срыву сроков.
- Фокусируйте усилия на цели и основном плане, а не на деталях исполнения. Их команда проработает уже в процессе.
- Постоянно актуализируйте бэклог продукта. Например, команда досрочно закончила задачи. Если в бэклог уже добавлены и отсортированы следующие по важности, исполнители могут взяться за них, не теряя времени.
- Помните, что невозможно спланировать все идеально. Главное — быстро реагировать на изменения и адаптироваться.
Как упростить планирование с помощью системы управления проектами Moo.Team
Небольшие команды поначалу используют для ведения бэклога обычные электронные таблицы или таск-менеджеры. Вскоре они сталкиваются с проблемами: не у всех членов команды есть доступ; кто-то случайно удалил строчку, и восстановить ее уже нельзя; ответственные не получают уведомления о статусе и дедлайнах. Очевидно, что необходима система управления проектами, которая позволит эффективнее достигнуть цели.
Moo.Team позволяет выполнять весь спектр действия по планированию и организации работы команды, в том числе:
- ставить задачи;
- менять их статус, сроки;
- группировать задания по проектам;
- назначать ответственных;
- делегировать задания;
- назначать повторяющиеся задачи;
- отслеживать процесс выполнения;
- представлять план работ в виде сводки или канбан-доски;
- регулировать доступы к задачам и проектам;
- автоматически уведомлять исполнителей о смене статуса, сроков и т.п.
За счет этого система управления проектами Moo.Team обеспечивает четкое и прозрачное управление бэклогом спринта, своевременное информирование команды об изменениях в нем.
Подведем итоги
- Scrum — гибкий подход к созданию продукта, где работа строится через спринты.
- В планировании спринта участвует бизнес (владелец продукта), регулятор (скрам-мастер), команда исполнителей.
- Все задачи вносятся в бэклог, который отражает прогресс, корректировки, приоритизацию работ.
- Команда должна понимать, почему она выполняет те или иные задачи. При этом важно учитывать мнение исполнителей относительно ценности и сложности задач.
- Встречи для планирования спринта — это не отчеты и не получение указаний, а живое профессиональное обсуждение.
- Система управления проектами помогает сформировать прозрачный бэклог, оперативно его актуализировать, отслеживать прогресс.
Главный редактор:
Михаил Струняшев
Иллюстратор:
Ильнар Карим