Что такое спринт в Scrum: цель, длительность и события

Спринт — это короткий повторяющийся отрезок времени, за который Scrum-команда превращает часть планов в готовый работающий результат. Разбираем, зачем нужен спринт, какой выбрать длительность, какие события его наполняют и какие ошибки чаще всего ломают ритм команды.

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

Спринт — это фиксированный по времени интервал (обычно от одной до четырёх недель), внутри которого команда планирует, делает и проверяет конкретный объём работы. Это базовая единица ритма в Scrum: один спринт заканчивается — сразу начинается следующий, без пауз между ними.

Главная идея спринта — работать короткими, предсказуемыми циклами вместо одного длинного забега к далёкому релизу. В конце каждого спринта у команды есть готовый кусок продукта, который можно показать и, в идеале, выпустить. Это снижает риск: вы регулярно проверяете, туда ли движетесь, и можете скорректировать курс, не дожидаясь конца проекта.

В отличие от Waterfall, где этапы идут последовательно и результат виден только в финале, спринт даёт обратную связь каждые пару недель. Это и есть суть гибкого подхода — учиться на ходу.

Цель спринта (Sprint Goal)

У каждого спринта должна быть одна понятная цель — Sprint Goal. Это короткая формулировка того, ради чего команда работает эти недели, а не просто список задач. Например: «дать пользователю возможность оплатить заказ картой» — это цель, а «сделать 12 тикетов» — нет.

Цель спринта помогает команде принимать решения. Если в середине спринта выяснилось, что какая-то задача не приближает к цели, её можно отложить. Если появилась задача, которая важна для цели, её обсуждают с владельцем продукта. Цель удерживает фокус и не даёт спринту превратиться в случайный набор дел.

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

Длительность спринта: как выбрать

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

• Одна неделя — много частой проверки и быстрая коррекция, но накладные расходы на события (планирование, обзор, ретро) занимают заметную долю времени.
• Две недели — золотая середина для большинства продуктовых команд: достаточно времени, чтобы сделать осмысленный кусок, и достаточно частая обратная связь.
• Три-четыре недели — подходит, когда требования стабильны, но цель отодвигается далеко и риск «уехать не туда» растёт.

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

События спринта: четыре встречи

Спринт состоит из четырёх событий — они задают его структуру и не дают работе расплыться.

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

Инкремент: результат спринта

Инкремент — это сумма всей завершённой работы за спринт плюс всё, что было сделано раньше. Ключевое слово — «завершённой»: задача считается частью инкремента, только если она соответствует определению готовности (Definition of Done) команды.

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

Чтобы отслеживать, как команда движется к завершению спринта, удобно смотреть на burndown-диаграмму — она показывает, успеваете ли вы закрыть взятый объём к концу итерации.

Частые ошибки при работе со спринтами

Даже опытные команды наступают на одни и те же грабли. Вот что чаще всего ломает ритм спринтов.

• Перегруз спринта. В спринт берут больше, чем команда реально закрывает. Опирайтесь на свою velocity, а не на оптимизм. Хроническое недовыполнение демотивирует.
• Спринт без цели. Если цели нет, спринт превращается в очередь задач, и команда теряет фокус.
• Изменение объёма на ходу. Добавление задач в середине спринта без обсуждения цели размывает результат. Срочное — в следующий спринт или с пересмотром цели.
• Незавершённые задачи переносятся бесконечно. Если задача не влезает в спринт, её, скорее всего, надо декомпозировать — см. декомпозицию работ.
• Формальные события. Дейли превращается в скучный отчёт, ретро не приводит к изменениям. Встречи должны давать пользу, иначе их саботируют.

Чтобы спринты были предсказуемыми, команде нужен прозрачный инструмент. В TeamVector задачи спринта связываются с коммитами в Git (GitLab), а диаграмма Ганта с критическим путём помогает видеть зависимости между задачами поверх итераций — это особенно полезно командам разработки, которым важна и гибкость спринтов, и понимание сроков по проекту в целом.

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