Планирование спринта: как подготовить и провести встречу

Вячеслав Степанов — проджект-менеджер, ментор · 30 октября 2026

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

Если видео не открывается, смотри на YouTube (может понадобиться VPN).

Что такое планирование спринта

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

Scrum Guide, официальное описание Scrum от его авторов Кена Швабера и Джеффа Сазерленда, в редакции 2020 года требует, чтобы цель была согласована до конца встречи. Там же сказано, что выбранные задачи разработчики обычно дробят на кусочки по одному дню работы или меньше. Ограничение по времени в Scrum Guide одно: до восьми часов для месячного спринта, для коротких спринтов меньше.

На встрече нужна вся команда разработки: техлид, бэкенд- и фронтенд-разработчики, тестировщик. Дизайнера и аналитика зовут, если задачи их касаются. Продакт-оунер приносит приоритеты. В классическом Scrum встречу помогает провести скрам-мастер, а в командах без скрам-мастера встречу часто ведёт проджект-менеджер.

Как подготовиться

Короткое планирование получается у тех, кто сделал основную работу заранее. Задачи, которые команда видит впервые, приходится разбирать с нуля прямо на встрече, оценки у разных людей расходятся в три–пять раз, и полтора часа превращаются в четыре.

Перед встречей верхние задачи бэклога должны соответствовать критериям готовности (Definition of Ready):

• бэклог отсортирован продакт-оунером по приоритету;
• у 5–10 верхних задач есть описание и критерии приёмки;
• задачи прошли груминг, и команда с ними знакома;
• видны зависимости между задачами и риски;
• в идеале у задач уже есть черновая оценка с груминга.

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

Бывает, что эпики в бэклоге есть, а задач внутри них ещё нет. После этапа исследования это обычная ситуация: команда раздробит эпик на планировании. Если же доска к встрече пустая, обсуждать на планировании нечего.

Как провести встречу

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

Самая длинная часть отведена разбору. Команда делит задачи на подзадачи, оценивает их и решает, кто чем займётся. Затем сумму оценок сравнивают с ёмкостью команды (capacity). Если работы набралось больше, лишнее убирают в следующий спринт, проговаривают риски и блокеры. Запас в конце уходит на споры по отдельным задачам и на «ой, забыл сказать».

Как считать ёмкость в часах и в Story Points, я подробно разбирал в статье про спринт. Здесь хватит одного правила: ёмкость задаёт потолок. Если по расчёту у разработчика 7,5 дня, задачи на 9,5 дня ему не ставят в надежде на высокую мотивацию.

Как сформулировать цель спринта

Цель спринта (Sprint Goal) пишется одним предложением и объясняет, зачем команда идёт в этот спринт. Самая частая ошибка: записать в цель перечень задач.

Цель описывает результат для продукта. Когда в середине спринта всплывёт сложность, команда сможет решить, что можно отложить без ущерба для цели. Подробнее о том, как цель помогает спринту, в статье про спринт.

Что делает проджект на встрече

Проджект на планировании работает фасилитатором, то есть ведущим, который помогает команде прийти к решению. Что он делает на встрече:

• Держит время: следит, чтобы обсуждение одной задачи не съело всю встречу, и вовремя переходит к следующей части.
• Задаёт команде вопросы: «Кто это делает?», «Зависимость с фронтендом учли?», «Дизайнер в эти две недели свободен?».
• Каждое решение, включая промежуточные, проджект записывает: кто что берёт, что перенесли, о чём договорились уточнить.
• Если задачу обсудили только со стороны бэкенда, проджект замечает пропуск и останавливает разговор: «Секунду, фронт по этой задаче мы не разобрали».

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

Кто и как оценивает задачи

Оценку даёт тот, кто будет делать задачу. Если задача затрагивает несколько ролей, каждый оценивает свою часть. Вот как это выглядело на планировании в учебной команде, где мы брали в спринт напоминания ученикам об уроке за 24 часа и за 1 час:

• Бэкенд-разработчик назвал 3 дня: фоновые задачи в проекте уже есть, шаблоны простые.
• Техлид попросил учесть два риска: одно напоминание не должно уйти дважды; если урок отменили, напоминание отправлять нельзя.
• Разработчик согласился и добавил день. Итого 4.
• Тестировщик оценил проверку в 1,5 дня: отмена и перенос урока, удалённый ученик, ученик без Telegram.
• Фронтенд-разработчица задачу не оценивала, потому что интерфейс она не затрагивает, но уточнила, увидит ли пользователь напоминание в личном кабинете.

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

Когда в одной роли несколько человек, например три бэкенд-разработчика, команды используют Planning Poker: все одновременно показывают карточки с оценкой, чтобы никто не подстраивался под чужую цифру. Как он устроен и чем Story Points отличаются от часов, описано в статье про оценку задач. Если оценка кажется завышенной, спроси, из чего она складывается. Разложив цифру на части вслух, исполнитель обычно сам видит, где заложил лишнее.

Что остаётся после встречи

В тот же день проджект оформляет протокол планирования в базе знаний команды, например в Confluence: цель спринта, взятые задачи, риски и все договорённости. Через неделю на дейлике кто-нибудь обязательно спросит «а мы это договаривались делать?», и ответ найдётся в протоколе.

В Jira к началу спринта у каждой задачи есть исполнитель и оценка, цель записана в описании спринта. После этого спринт запускают, и команда начинает работу.

Типичные ошибки

• Проджект оценивает за команду, но его «Ну это, наверное, дня три» остаётся догадкой. Спроси исполнителя и запиши его цифру.
• Команда берёт больше ёмкости. «Ничего, отработаем» заканчивается сорванным спринтом и тяжёлой ретроспективой. Лишние задачи переносят в следующий спринт ещё на встрече.
• Цель спринта записана списком задач, и выбрать по ней, что отложить, нельзя. Сформулируй результат для продукта одним предложением.
• Оценки ставят без обсуждения. «Пусть будет пять» звучит быстро, но через пару дней на дейлике выясняется, что задачу каждый понимал по-своему. Помогает короткий вопрос исполнителю: что входит в эту оценку.
• Решения не записывают в протокол. Договорённости забываются, и одно и то же решение принимают второй раз, иногда с другим итогом.

Частые вопросы