Привет, Хабр!

Иногда кажется, что команда вроде бы стабильная, спринты идут по плану — а под конец снова в панике жмёмся к дедлайну, выкидываем фичи и дорабатываем вечерами. Чтобы такого не происходило, я хочу рассказать про простую и очень рабочую модель — 3–3–3. Она помогает прогнозировать скорость команды без гаданий на story points и держать реалистичный фокус: сколько мы реально успеем, а не сколько хочется.

Почему story points не дают предсказуемости

Story points — это не метрика, а договорняк. В команде просто говорят: «Окей, эта задача — где‑то на пятёрку». Кто‑то меряет по количеству условий в задаче, кто‑то по глубине копания в легаси, кто‑то по тому, насколько больно будет деплоить. Всё это — ощущения, а не числа. И вот тут‑то и проблема: без контекста эти поинты ничего не значат.

Команда А может честно вкладывать в «пятёрку» три дня работы. Команда Б — день. И обе будут уверены, что всё делают правильно. Ну и как вы это потом нормализуете в прогноз?

План — это хотелка. Прогноз — это реальность.

Вот тут многие путаются. План — это когда команда говорит: «Берём 40 поинтов. Справимся!». А прогноз — это когда ты встаёшь перед зеркалом и говоришь: «Ну, дай бог хотя бы 25 вытянем, если прод не ляжет».

Проблема в том, что планируют по желанию, а живут — по фактам.

Команда берёт 40 просто потому, что в прошлый раз получилось. А то, что в прошлом спринте:

• никто не свалил в отпуск,

• CI не валился 3 дня подряд,

• и багов прод не навалил...

— забывают. И снова ставят на сороковник. А потом удивляются, почему в релиз не влезли. Потому что 40 story points — это не обещание, а диапазон. И этот диапазон может болтаться от 20 до 45 в зависимости от погоды, соседней команды и прочих факторов.

Среднее — это ложь, если не видеть разброс

Опираясь на одно число velocity, вы получаете красивую иллюзию контроля. Но это как говорить «у нас средняя температура по больнице 36.6» — пока не глянешь, что у кого‑то уже труп, а у кого‑то лихорадка. То же самое со спринтом: стабильность — это миф, если вы не считаете отклонения.

Планировать максимум ≠ прогнозировать минимум

Когда вы планируете — вы, как правило, хотите влезть в максимум: «ну мы же справимся, если не будет форс‑мажоров». Они будут.

А вот прогноз — это честный ответ на вопрос «а сколько успеем, если всё пойдёт как обычно?». И вот тут‑то внезапно выходит, что одни и те же 40 SP в плане и прогнозе — это не одно и то же. Потому что в плане мы дерзим, а в прогнозе мы думаем.

Когда пора включать голову

Вот в такие моменты и появляется потребность в чём‑то менее наивном, чем просто «брать как в прошлый раз».

Нужна модель, которая:

• не требует кристально чистых данных,

• учитывает, что команда живёт в реальном мире, а не в scrum‑гайдлайнах,

• даёт понятный язык общения с продактом: не «успеем/не успеем», а «мы движемся в диапазоне от 80 до 120 поинтов — выбирай, с чем тебе комфортно».

И вот именно под это заточена модель 3–3–3. Простая, но спасает.

Что такое модель 3–3–3

Модель строится по принципу честной статистики: мы не угадываем, а смотрим на факты. Алгоритм предельно простой и укладывается в одну строку:

Возьми 3 спринта, посчитай min / median / max velocity — и получи 3 прогноза.

Распишу по шагам.

Берём 3 прошлых спринта

Берём именно 3 — не 5, не 10, не весь год. Почему? Потому что контекст меняется слишком быстро: люди болеют, уезжают в отпуск, приходят новички. Три спринта дают срез последних 1.5 месяцев работы команды в живом виде. Этого достаточно, чтобы увидеть тренд и не утонуть в шуме.

Пример:

Sprint 14 — 32 SP
Sprint 15 — 27 SP
Sprint 16 — 40 SP

Считаем три диапазона: min / median / max

• min = 27 SP

• median = 32 SP

• max = 40 SP

Это три сценария на будущее:

• Пессимистичный (27) — если всё пойдёт не так.

• Реалистичный (32) — если всё будет как обычно.

• Оптимистичный (40) — если никто не отвлечётся и не упадёт прод.

Мы не предсказываем, а ограничиваем ожидания. Это основа риск‑ориентированного планирования.

Строим три сценария прогноза

Теперь можно делать форекаст. Например, осталось 3 спринта до релиза. Нужно понять, сколько задач реально можно успеть.

Остаток задач в story points: 90

Прогноз:

- pessimistic: 3 * 27 = 81 → не успеваем
- realistic: 3 * 32 = 96 → на грани
- optimistic: 3 * 40 = 120 → с запасом

Отсюда сразу видно: с текущим бэклогом на 90 SP есть риск не успеть, если произойдут сбои. И это — сигнал поговорить с продуктом.

Как использовать модель в планировании

Три прогноза = разговор о рисках

Вместо одного числа velocity, которое никого не волнует, теперь три чётких прогноза, и это повод обсудить риски.

Пример:

— Мы хотим взять фичи на 40 SP.
 — По pessimistic velocity мы успеваем на 81 SP за 3 спринта. Значит, если хотя бы один спринт провалится — фичи не войдут.

Продукт понимает, где риск, а команда — где резерв.

Когда не хватает времени — сдвигаем или упрощаем

Если по pessimistic velocity видно, что вы не влезаете — это не повод молча идти и «херачить». Это сигнал, что нужно либо резать фичи, либо двигать сроки.

Главное, что эта модель позволяет обсуждать это до того, как команда влетела в переработки.

Автоматизации модели

Чтобы модель приносила пользу не разово, а системно — её нужно встроить в процесс. Наиболее простой путь — Google Sheets. Если вы на Jira — дополнительно пригодятся JQL‑выгрузки и графики на базе burnup.

Google Sheets: быстрый шаблон, который работает

Создаём простую таблицу:

Дополнительно, рядом или под таблицей, считаем три сценария:

Минимум:  =MIN(B2:B4)
Медиана:  =MEDIAN(B2:B4)
Максимум: =MAX(B2:B4)

После чего рассчитываем прогноз на 3 спринта:

Min forecast:  =MIN(B2:B4) * 3
Med forecast:  =MEDIAN(B2:B4) * 3
Max forecast:  =MAX(B2:B4) * 3

Дополнительно можно добавить строку с текущим объёмом бэклога (например, 85 SP), и сразу видеть:

=IF( [Прогноз] >= [Scope], "Ок", "Риск" )

Такую таблицу можно делать на один релиз: в одной вкладке — raw‑данные, в другой — сценарии и визуализация.

Jira: вытягиваем данные через JQL

Если вы работаете в Jira, velocity можно получить двумя способами: вручную через борды, либо через JQL и dashboard.

Пример запроса JQL:

project = MYPROJ AND sprint in closedSprints() ORDER BY sprint DESC

После выполнения запроса:

• Фильтруйте задачи по статусу «Done»

• Суммируйте Story Points в каждом спринте

Если хотите полуавтомат — можно использовать Jira Automation, чтобы автоматически собирать velocity в custom field или записывать в внешний источник (например, ту же Google Sheet через webhook).

Вариант через REST API:

Если команда большая и velocity нужен регулярно:

• Пишем скрипт с авторизацией в Jira API

• Парсим board, получаем последние N закрытых спринтов

• Суммируем SP по статусу Done

• Отдаём значения в Sheet или Prometheus

Burnup-график: визуализация трёх прогнозов

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

Берём burnup‑график и добавляем три линии:

• Общий объём задач (scope) — горизонтальная линия

• Пессимистичный прогноз — линия, идущая от текущего значения по min velocity

• Реалистичный прогноз — линия по median velocity

• Оптимистичный прогноз — по max velocity

Ключевая идея:

• Если pessimistic‑прогноз не достигает scope до конца релиза — команда в зоне риска

• Если median достигает — проект на грани

• Если даже min уверенно пересекает — резерв есть

Такой график можно собрать в Google Sheets, Excel или через плагин в Jira.

Заключение

Модель 3–3–3 — простой инструмент, чтобы перевести команду из режима ожиданий в режим управления. Она заставляет смотреть на реальные данные, видеть диапазоны, принимать решения. И самое главное — говорить о рисках до того, как они стали проблемами.

Если вы тимлид и держите фокус не только на спринтах, но и на росте команды — посмотрите в сторону корпоративных программ OTUS. Это обучение, которое не отвлекает от дела, а усиливает: программирование, DevOps, аналитика, управление — всё с прицелом на реальные задачи и гибкую интеграцию в процессы. Без формальностей, но с результатом.

Чтобы оставаться в курсе актуальных трендов управления в IT и первыми узнавать новости о бесплатных мероприятиях, подписывайтесь на Telegram-канал OTUS4Business.