Что такое спринт в IT простыми словами: сколько длится и как устроен

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

«Возьмём в спринт», «не влезает в спринт», «перенесём на следующий спринт» — эти фразы новичок слышит в IT-команде с первого дня. Спринт задаёт ритм всей работы, и проджект-менеджер отвечает за то, чтобы этот ритм не сбивался. Ниже — что такое спринт, сколько он длится, из каких встреч состоит, как ставят цель и считают, сколько задач брать. Видео-версия — мой открытый урок про планирование спринта, сразу ниже.

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

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

Спринт (sprint, итерация) — это отрезок времени фиксированной длины, за который команда берёт в работу набор задач и доводит их до готового результата. Слово пришло из Scrum — фреймворка, который придумали Кен Швабер и Джефф Сазерленд. Правила Scrum описаны в их руководстве Scrum Guide.

Смысл спринта — разбить большую работу над продуктом на короткие одинаковые циклы. Вместо плана на год команда договаривается о ближайших двух неделях: что делаем, кто делает и какой результат покажем в конце. Через две недели — новый спринт, новая порция работы и новый план с учётом того, что узнали.

Результат спринта называется инкремент — то, что добавилось к продукту и уже работает. «Почти готово» инкрементом не считается: у команды есть общий список критериев готовности (Definition of Done), и задача засчитывается, только если прошла его целиком.

Сколько длится спринт

Scrum Guide ставит одно жёсткое ограничение: спринт длится не больше месяца, длина у всех спринтов одинаковая, а следующий начинается сразу после предыдущего — без пауз «на передышку».

На практике команды выбирают от одной до четырёх недель, и чаще всего — две. Это баланс: за неделю сложно довести что-то крупное до готового состояния, а за месяц накапливается слишком много неопределённости и бизнес долго ждёт результата. Двухнедельный спринт — это 10 рабочих дней: достаточно, чтобы сделать заметную часть продукта, и достаточно мало, чтобы быстро поправить курс.

Спринты нумеруют подряд: «Спринт 14», «Спринт 15». По номеру легко найти в трекере задачи, протоколы встреч и итоги конкретных двух недель.

Из чего состоит спринт

• Планирование спринта (Sprint Planning) — первая встреча. Команда формулирует цель спринта и выбирает задачи. По Scrum Guide на месячный спринт планирование занимает до 8 часов, на короткие — меньше. В хорошо подготовленной команде на двухнедельный спринт хватает полутора часов.
• Работа и дейлики. Каждый день команда встречается на 15 минут и сверяется: кто что сделал, что делает сегодня, что мешает. Подробно — в статье про дейлик.
• Груминг — встреча внутри спринта, на которой команда заранее разбирает задачи для следующего спринта: уточняет, дробит, прикидывает оценки. Благодаря ей следующее планирование проходит быстро.
• Демо (Sprint Review) — команда показывает готовый результат стейкхолдерам на живом продукте и собирает отзывы.
• Ретроспектива — команда разбирает не продукт, а свою работу: что помогало, что мешало, что изменить. Подробно — в статье про ретроспективу.

Все задачи спринта живут на доске в трекере — например, в Jira. Такой список называется бэклог спринта (Sprint Backlog): что именно команда взяла на эти две недели. Всё остальное, что когда-нибудь нужно сделать, лежит в общем бэклоге продукта и ждёт своей очереди.

Цель спринта

Цель спринта (Sprint Goal) — одно предложение о том, ради чего команда идёт в эти две недели. Например: «Закрыть Telegram-бот и снять техдолг по аутентификации». Цель предлагает проджект-менеджер после разговора с продакт-оунером, а команда на планировании подтверждает её или уточняет.

Частая ошибка — записать в цель список задач: «Сделать задачи 31, 20 и 2». Это состав работ, по нему не видно, зачем всё это. Хорошая цель понятна человеку вне команды и помогает решать споры посреди спринта: если новая срочная просьба не двигает цель, она подождёт.

Сколько задач брать в спринт

Главный вопрос планирования — сколько работы команда реально успеет. Для этого считают capacity — потолок по объёму работы на спринт. Способ зависит от того, как команда оценивает задачи.

Если команда оценивает в часах и днях

Capacity считают на каждого человека. Берут все рабочие часы спринта и вычитают из них то, что на задачи не пойдёт: отпуска, встречи спринта и запас на прерывания.

Если по оценкам на человека приходится больше — значит, спринт перегружен. Часть задач уходит в следующий спринт.

Если команда оценивает в Story Points

Story Points — относительная оценка сложности задачи по шкале 1, 2, 3, 5, 8, 13. Здесь capacity считают на всю команду через velocity — сколько поинтов команда реально закрывала в прошлых спринтах.

Пример: за последние три спринта команда закрыла 42, 38 и 45 поинтов. Среднее — около 42. От него берут скидку 15% на риски и непредсказуемость: 42 × 0,85 ≈ 35. Значит, в следующий спринт стоит брать задачи примерно на 35 поинтов.

Можно ли менять задачи посреди спринта

По Scrum Guide состав работ внутри спринта можно уточнять и пересогласовывать с продакт-оунером, но нельзя вносить изменения, которые ставят под угрозу цель спринта. Если цель вдруг потеряла смысл — например, бизнес резко сменил приоритеты, — спринт можно отменить. Такое право есть только у продакт-оунера.

В жизни большинство продуктовых команд работает по гибриду — скрамбану. Там срочное, например упавший прод, берут в работу сразу. Но это осознанное решение: что-то из спринта при этом уходит, и команда проговаривает это вслух.

А что с задачами, которые не успели? Они не считаются сделанными и не показываются на демо — возвращаются в бэклог продукта. Дальше продакт-оунер решает, брать ли их в следующий спринт. Причины разбирают на ретроспективе: недооценили, отвлекли срочные просьбы или взяли больше capacity.

Что делает проджект-менеджер в спринте

• Готовит планирование. Заранее сверяет приоритеты с продакт-оунером, проверяет, что у верхних задач бэклога есть описание и критерии приёмки, учитывает отпуска команды, пишет черновик цели.
• Ведёт встречи. Держит время, задаёт уточняющие вопросы («а зависимости с фронтендом учли?»), фиксирует решения в протоколе. Что брать — решает продакт-оунер, сколько займёт — отвечает исполнитель; проджект-менеджер создаёт условия, в которых эти решения принимаются осознанно.
• Следит за ходом спринта. Через дейлики и доску видит, где задача застряла, и снимает блокеры.
• Закрывает спринт. Собирает сценарий демо, проводит ретро и следит, чтобы договорённости превратились в задачи.

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

• Проджект-менеджер оценивает задачи сам. «Ну это, наверное, три дня» — это догадка. Лекарство — оценку даёт тот, кто будет делать, а PM спрашивает, из чего она складывается.
• Берут больше capacity. Команда выгорает, демо проваливается. Лекарство — считать capacity до планирования и резать объём, если перебор.
• Цель спринта — список задач. Лекарство — одно предложение о смысле: зачем идём в эти две недели.
• Пустой бэклог на планировании. Задачи обсуждают с нуля, встреча растягивается в несколько раз, оценки гуляют. Лекарство — груминг заранее: к планированию верхние задачи уже понятны команде.
• Решения не записаны. Через неделю никто не помнит, о чём договорились. Лекарство — протокол планирования в базе знаний команды в тот же день.

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