Планирование спринта

Как за пару часов договориться о том, что команда сделает за две недели — и почему разговор про цель важнее разговора про задачи.

Планирование спринта (Sprint Planning) — встреча в начале спринта, на которой команда отвечает на три вопроса: зачем этот спринт нужен, что мы в нём сделаем и как мы за это возьмёмся.

Зайдите на любое планирование в средней компании — и услышите что-то вроде: «Так, у нас 40 сторипоинтов ёмкости, тащим верх бэклога, пока не наберём». Люди расходятся, каждый берёт свои задачи, через две недели половина не доделана. Формально всё по Scrum: встреча была, задачи в спринте есть. По сути — команда просто разгрузила очередь на две недели вперёд.

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

Три вопроса планирования

Scrum Guide формулирует повестку как три темы. Порядок здесь не случайный — если начать со второй, первую уже не восстановишь.

Цель спринта: главное и самое пропускаемое

Цель спринта (Sprint Goal) — одно-два предложения, описывающие результат спринта с точки зрения пользователя или бизнеса. Не список задач, а именно результат.

По моему опыту это первое, что отваливается, когда команда «оптимизирует» церемонии. Цель кажется формальностью: ну да, напишем что-нибудь в заголовок доски. А потом наступает четверг второй недели, приходит срочный баг, и никто не может ответить на вопрос «что мы можем выкинуть». Потому что выкидывать не из чего: спринт — это плоский список из 17 несвязанных задач, каждая кому-то нужна.

Разница простая: у правой колонки есть критерий «достигли или нет», который поймёт человек вне команды. И, что важнее, у неё есть гибкость. Если цель — «пользователь может оплатить картой», то сохранение карты «на потом», красивая анимация загрузки и рефакторинг платёжного сервиса — это приятные дополнения, которые можно выкинуть в среду и всё равно закрыть спринт. Цель — это то, ради чего можно пожертвовать остальным.

Как формулировать цель, если спринт «разношёрстный»

Частое возражение: «У нас в спринте платёжка, три бага из поддержки и миграция базы — какая тут общая цель?» Ответ обычно один из двух.

• Спринт всё-таки про что-то одно, а остальное — фон. Тогда цель описывает главное, а баги живут отдельной строкой как «текущая поддержка, до 20% времени».
• Спринт действительно ни про что. Это плохой признак: команда работает как бюро заявок, а не как продуктовая команда. Стоит показать это на ретро, а не прятать за красивой формулировкой.

Выбор задач под ёмкость

Ёмкость (capacity) — сколько работы команда реально способна взять в этот конкретный спринт. Не «сколько влезет в идеальном мире», а с учётом отпусков, дежурств, собеседований и релизной суеты.

Практический приём: перед планированием посчитать доступные человеко-дни, а не полагаться на среднюю скорость (velocity) из прошлых спринтов. Средняя скорость — хороший ориентир, но она молчит о том, что Аня в отпуске, а Игорь всю неделю дежурит по инцидентам.

Спринт 35 (10 рабочих дней), команда из 5 разработчиков

Аня      10 дней  −5 (отпуск)          =  5
Игорь    10 дней  −5 (дежурство)       =  5
Марат    10 дней                       = 10
Лена     10 дней  −1 (конференция)     =  9
Дима     10 дней  −2 (онбординг новичка) = 8
---------------------------------------------
Итого                                   = 37 человеко-дней
Минус 20% на поддержку и внезапное       = ~30

Средняя velocity за 3 спринта: 34 SP при ~45 человеко-днях
Берём в спринт: ~22-24 SP

Цифры условные, но логика важна: сначала считаем реальность, потом набираем задачи, а не наоборот. Команды, которые каждый спринт берут «как обычно», а потом каждый спринт не доделывают, обычно просто не смотрят в календарь отпусков.

Готовность задачи

На планирование нельзя приносить сырое. Если задача формулируется как «надо разобраться с уведомлениями», планирование превращается в аналитическую сессию на три часа, и все злятся. Отсюда практика Definition of Ready — договорённость о том, какую задачу вообще можно брать в спринт: есть понятная ценность, есть критерии приёмки, нет неизвестных внешних зависимостей, команда представляет размер. Груминг бэклога делают до планирования, а не на нём.

Коммитмент или прогноз

Тонкий, но принципиальный момент. В ранних версиях Scrum Guide команда «обязывалась» (commit) выполнить набор задач. В 2011 году слово заменили на «прогноз» (forecast) — и это не игра в термины.

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

Обязательство остаётся, но оно про цель, а не про список задач. Команда обязуется сделать всё разумное, чтобы достичь цели спринта; она не обязуется закрыть ровно 24 сторипоинта. Разница чувствуется в тот момент, когда что-то идёт не по плану — а идёт оно не по плану примерно всегда.

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

Как это работает

Таймбокс планирования — до 8 часов для месячного спринта, то есть примерно 2 часа для двухнедельного. Реально хорошая встреча укладывается в полтора часа и выглядит так:

1. Product Owner на 10 минут рассказывает, что происходит с продуктом и что важно сейчас.
2. Команда обсуждает и формулирует цель спринта. Записывает её на доску. Вслух.
3. Разработчики отбирают из бэклога то, что закрывает цель, сверяясь с ёмкостью.
4. Крупные элементы разбивают на задачи. Не обязательно все — достаточно на первые дни, дальше декомпозируют по ходу.
5. Проверка: «Если мы сделаем вот это — цель достигнута? Мы верим, что успеем?» Если кто-то не верит, это говорят сейчас, а не на ретро.

Итог планирования — бэклог спринта (Sprint Backlog): цель + отобранные элементы + план, как за них взяться.

СПРИНТ 35  (14-27 марта)

ЦЕЛЬ: Пользователь может оплатить заказ картой
      и получить чек на почту.

В спринте:
  [8] Интеграция с платёжным провайдером (happy path)
  [5] Форма оплаты на странице заказа
  [3] Обработка отказа банка + понятная ошибка
  [5] Отправка чека на email после успешной оплаты
  [2] Логи и алерт на падение платежей
  ------------------------------------------------
  Итого 23 SP при ёмкости ~24

Если не успеваем — режем: алерт (2), можно после спринта.
НЕ режем: обработку отказа — без неё цель не достигнута.

Последние две строки — признак зрелой команды. Про них почти всегда забывают, а именно они спасают спринт в четверг второй недели.

Частые ошибки

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

Итоги

• Планирование отвечает на три вопроса — зачем, что и как. Начинать нужно с «зачем».
• Цель спринта — одно предложение о результате для пользователя. Она позволяет резать объём, не проваливая спринт.
• Ёмкость считают по календарю (отпуска, дежурства), а не по средней скорости прошлых спринтов.
• Команда даёт прогноз, а не обещание. Обязательство — перед целью, не перед списком задач.
• Итог встречи — бэклог спринта: цель, задачи и понимание, что резать первым.