Перейти к основному контенту
CI CONSULT
Загрузка...
CI Consult · Scrum Framework · Протокол

Цикл подготовки спринта

Полный протокол от приоритизации бэклога до коммита команды. 8 последовательных шагов для двухнедельного спринта в консалтинговой команде.

8
Шагов в цикле
~3 ч
Общее время
90 мин
Рефайнмент
85 мин
Планирование
14 дн
Длина спринта

Сначала ценность, потом трудоёмкость, потом отбор. Не оценивай то, что не возьмёшь. Не бери то, что не оценил.

Ключевой принцип последовательности
Обзор · Таймлайн спринта (Sprint Timeline)
Когда что происходит
Каждый шаг привязан к конкретному дню двухнедельного спринта. Нарушение последовательности ломает весь цикл.
Дни 1–5
Бэклог
PO постоянно обновляет приоритеты бэклога по ценности
Шаг 1
Дни 5–7
Рефайнмент
Команда разбирает задачи, оценивает покером
Шаг 2 · 60–90 мин
Дни 8–9
Подготовка
SM считает ёмкость и готовит Miro-доску
Шаги 3–4 · 35 мин
День 10
Планирование
Цель → Отбор → Декомпозиция → Коммит
Шаги 5–8 · 85 мин
1 Ценность
2 Трудоёмкость
3–4 Подготовка
5–8 Планирование
01
Приоритизация бэклога
Product Owner ранжирует задачи по бизнес-ценности (Backlog Prioritization)
01
Постоянно · Владелец продукта (Product Owner)
Ранжирование по ценности
PO собирает входящие запросы от клиентов, стейкхолдеров и команды — и выстраивает бэклог так, чтобы самое ценное было наверху.
Последовательность действий
1
Собрать входящие запросы: от клиентов, стейкхолдеров, команды
PO
2
Оценить каждую задачу по ценности: «Что получит клиент / бизнес?»
PO
3
Ранжировать бэклог: самое ценное — наверху. Задачи без ясной ценности — не попадают в топ
PO
4
Сформулировать предварительную цель следующего спринта
PO
📥 Входы
Обратная связь от клиентов
Стратегические приоритеты компании
Техдолг от команды
📤 Выходы
Отсортированный бэклог
Топ-10 задач-кандидатов
Черновик цели спринта
🏢 Для консалтинга
В консалтинге PO — часто руководитель проекта. Приоритеты диктуются клиентскими дедлайнами и контрактными обязательствами. Это нормально — но команда должна это понимать.
🚫 Антипаттерн
PO не обновляет приоритеты между спринтами — команда работает по устаревшему списку. Результат: спринт заканчивается, а сделанное уже неактуально.
02
Рефайнмент бэклога
Команда оценивает трудоёмкость задач покером (Backlog Refinement)
02
Середина спринта · PO + Команда · 60–90 минут
Оценка трудоёмкости
Команда разбирает топ-задачи из бэклога: уточняет scope, формулирует критерии приёмки, оценивает в story points.
💡 Рефайнмент — самая недооценённая церемония. Без него планирование превращается в 3-часовой марафон.
Последовательность действий
1
PO представляет задачу из топа: ценность, контекст, ожидаемый результат
PO
2
Команда задаёт вопросы: «Что входит? Что НЕ входит? Какие зависимости?»
Team
3
Команда формулирует определение готовности (Definition of Done) для задачи
Team
4
Planning Poker: каждый показывает оценку → обсуждение расхождений → консенсус
Team
5
Повторяют для каждой задачи, пока не разобрали 1.5–2× от ёмкости спринта
Все
6
Слишком крупные задачи (>8 SP) — декомпозируют прямо на рефайнменте
Team
📥 Входы
Топ-10 задач с приоритетами от PO
Velocity последних 3 спринтов
📤 Выходы
Оценённые в SP задачи
Уточнённые DoD
Декомпозированные эпики
📌
Оцениваем 1.5–2× от ёмкости — чтобы на планировании был запас задач для выбора. Если оценить ровно на 1 спринт, команда лишится гибкости при отборе.
🚫 Антипаттерн
Рефайнмент не проводится → вся оценка переезжает на планирование → планирование длится 3+ часа и все устали ещё до начала спринта.
03
Расчёт ёмкости
Scrum Master считает реальную пропускную способность команды (Capacity Planning)
03
За 1–2 дня до планирования · Скрам-мастер · 15 минут
Сколько мы реально можем взять
SM рассчитывает ёмкость команды с учётом отпусков, клиентских дежурств и параллельных проектов.
Формула ёмкости
Ёмкость = (Рабочие дни × Кол-во людей) − Отпуска − Дежурства × Focus Factor

Пример: (10 дн × 5 чел) − 2 отпуска − 5 дежурств = 43 чел-дня × 0.7 = ~30 чел-дней
При velocity ~8 SP/чел → берём ~35–40 SP с 15–20% буфером на ad-hoc клиентские запросы
⚡ Focus factor в консалтинге: 0.6–0.7, а не 0.8. Много времени уходит на коммуникацию с клиентами.
📥 Входы
Календарь команды
История velocity (3 спринта)
План командировок
📤 Выходы
Ёмкость в SP на спринт
Список ограничений
🚫 Антипаттерн
Ёмкость не считается → команда берёт «сколько PO скажет» → хронический перегруз и недофиниш из спринта в спринт.
04
Подготовка доски
Скрам-мастер готовит пространство в Miro (Board Setup)
04
За 1 день до планирования · Скрам-мастер · 20 минут
Настройка рабочего пространства
Шаблон доски — одноразовая инвестиция. Один раз настроил — копируешь каждый спринт за 2 минуты.
Чеклист подготовки
1
Создать фрейм Sprint Planning с зонами для каждого этапа
SM
2
Подготовить секцию «Цель спринта» — крупно, на видном месте
SM
3
Разместить стикеры-кандидаты из рефайнмента (уже с оценками SP)
SM
4
Создать колонки: Бэклог → В работе → Ревью → Готово
SM
5
Добавить парковку для вопросов и блокеров
SM
6
Отправить приглашение: время, ссылка на Miro, повестка
SM
🚫 Антипаттерн
Доска создаётся на ходу во время планирования → 20 минут времени всей команды (5 чел × 20 мин = 100 чел-минут) уходит на наблюдение за «настройкой Miro».

Всё что до этого момента — подготовка. Всё что после — Sprint Planning. Команда садится вместе, и за 85 минут рождается спринт.

Начало церемонии планирования
05
Цель спринта
PO формулирует, команда обсуждает и принимает (Sprint Goal)
05
Первый день нового спринта · PO → Команда · 15 минут
Зачем мы это делаем?
Одно предложение, ориентированное на результат. Не список задач, а ответ на вопрос «Что изменится через 2 недели?»
✅ Хорошая цель

«Передать клиенту отчёт VSA и получить обратную связь на результаты диагностики»

❌ Плохая цель

«Поработать над проектом и закрыть 12 тикетов из бэклога»

Последовательность действий
1
PO озвучивает бизнес-контекст: что изменилось с прошлого спринта
PO
2
PO формулирует цель — одно предложение, ориентир на результат
PO
3
Команда задаёт вопросы: «Почему это? Что будет если не успеем?»
Team
4
Команда может скорректировать формулировку
Team
5
Цель записывается крупно на доске — не меняется до конца спринта
SM
🏢 Для консалтинга
Цель привязана к клиентскому результату. Не «сделать отчёт», а «передать клиенту отчёт и получить обратную связь». Разница — в фокусе на outcome, а не output.
06
Отбор задач
Команда набирает задачи сверху вниз, пока не заполнит ёмкость (Sprint Backlog Formation)
06
Сразу после цели · PO + Команда · 30 минут
Что берём в спринт
Задачи уже оценены на рефайнменте. Теперь команда отбирает их по одной — сверху вниз — пока не заполнит 80–90% ёмкости.
🎯 Не набирайте 100% ёмкости. В консалтинге ВСЕГДА прилетает что-то срочное от клиента. 15–20% буфер — не лень, а реализм.
Последовательность действий
1
PO представляет задачу #1 (уже оценённую): ценность + связь с целью спринта
PO
2
Команда подтверждает: «Берём» или «Есть вопрос / блокер»
Team
3
Если задача не была на рефайнменте — быстрая оценка покером прямо здесь
Team
4
SM ведёт счёт: набранные SP vs ёмкость спринта
SM
5
Повторяют по одной задаче, пока ёмкость не заполнена на 80–90%
Все
⚠️
Команда берёт 120% ёмкости «чтобы точно было что делать» — самый частый антипаттерн. Результат: хронический недофиниш, выгорание, потеря доверия к спринтам как инструменту.
07
Декомпозиция
Каждая задача разбивается на подзадачи ≤ 1 рабочего дня (Task Decomposition)
07
После отбора · Команда · 30 минут
Как именно мы это сделаем
Момент истины: если задачу нельзя разбить на шаги — она плохо понята. Каждый подшаг — не более 1 рабочего дня.
Последовательность действий
1
Берём задачу из Sprint Backlog: «Какие конкретные шаги нужны?»
Team
2
Каждый подшаг ≤ 1 дня работы. Если больше — дробим дальше
Team
3
Определяем зависимости: кто кого блокирует, что нужно сделать первым
Team
4
Отмечаем внешние зависимости: доступы от клиента, согласования, данные
Team
5
Блокеры и риски фиксируем на парковке
SM
🔧 «Ну там и так понятно, не будем разбивать» → через 3 дня задача оказывается в 3 раза больше.
💡
Не назначайте ВСЕ задачи сразу. Оставьте часть подзадач без ответственного — команда разберётся на ежедневных стендапах. Это развивает самоорганизацию.
08
Коммит команды
Каждый член команды явно подтверждает: «Да, это реалистично» (Team Commitment)
08
Финал встречи · Вся команда · 10 минут
Обещание команды самой себе
Коммит — не приказ сверху. Это осознанное обещание каждого члена команды. После этого момента Sprint Backlog зафиксирован.
Последовательность действий
1
SM зачитывает цель спринта и итоговый Sprint Backlog
SM
2
SM озвучивает нагрузку: «Мы берём X SP из Y ёмкости»
SM
3
Вопрос каждому лично: «Ты веришь, что мы это сделаем?»
SM
4
Если есть сомнения — открытое обсуждение: что убрать или заменить
Team
5
Финальное «Да» от каждого участника. Sprint Backlog зафиксирован
Все
🤝 Молчание ≠ согласие. Если кто-то молчит — SM спрашивает лично. Невысказанное сомнение — бомба замедленного действия.
🔒
После коммита — Sprint Backlog заморожен. PO не добавляет задачи. Если через 3 спринта это станет нормой — коммит потеряет смысл, и команда перестанет верить в планирование.
🚫 Антипаттерн
«Ну вроде ок» — без реального обсуждения рисков. PO добавляет «ещё одну маленькую задачку» после коммита. Результат: коммит обесценивается за 2–3 спринта.
Сводка · Все шаги (Full Cycle Summary)
Полный цикл одним взглядом
Цикл подготовки спринта · 8 шагов
Шаг Когда Кто Время Ключевой выход
01 Приоритизация бэклога Постоянно PO Отсортированный бэклог
02 Рефайнмент Середина спринта PO+Team 60–90 мин Задачи оценены в SP
03 Расчёт ёмкости За 1–2 дня SM 15 мин Ёмкость в SP
04 Подготовка доски За 1 день SM 20 мин Готовая Miro-доска
05 Цель спринта День планирования PO→Team 15 мин Согласованная цель
06 Отбор задач После цели PO+Team 30 мин Sprint Backlog
07 Декомпозиция После отбора Team 30 мин Подзадачи + зависимости
08 Коммит Финал встречи Все 10 мин Осознанное обещание
Результат цикла
8 шагов → 1 спринт
Ценность → Трудоёмкость → Отбор → Коммит. Каждый раз. Без исключений.