Почему тимлид не может сказать, сколько команда сделает в следующем спринте, и как я это посчитал

Если спросить тимлида «сколько story points команда сделает в следующем спринте?», чаще всего ответ будет такой: «Ну, в прошлый раз было около 300, давай возьмём столько же». Потом выясняется, что двое уходят в отпуск, один новичок ещё не разогнался, а треть времени съедят баги. Спринт заканчивается авралом, задачи доделывают в последние два дня, и этот аврал попадает в статистику как «нормальная скорость команды». Следующий план строится уже на нём.

Я руковожу кросс-функциональной командой внутреннего продукта в крупной компании: аналитика, дизайн, фронтенд, бэкенд и QA, около десяти человек. Около двух лет я планирую спринты по формуле, а не по ощущениям. Ниже расскажу, как устроен расчёт, какие у него ограничения и насколько он точен на реальных цифрах.

Как было раньше

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

Многие команды, которые я вижу, до сих пор так и работают: планируют по ощущениям, немного сверяясь с прошлыми месяцами. Проблему точности они решают сильным завышением оценок. Задача на день оценивается в 8 SP «на всякий случай», и через полгода story points уже ничего не значат. Это инфляция SP: план выполняется, но никто не понимает, сколько команда реально может сделать.

Мне хотелось обратного: честные оценки и при этом точный план.

С чего началось: таблица

Сначала задача была совсем простой: посчитать прогноз следующего спринта по прошедшим. Я завёл Google-таблицу и начал записывать по каждому спринту, сколько story points закрыли.

Довольно быстро стало ясно, что «среднее количество SP за спринт» ничего не прогнозирует:

• спринты разной длины: в одном 23 рабочих дня, в другом 9 из-за праздников;

• люди уходят в отпуск и болеют, причём неравномерно;

• новички первые месяцы работают не в полную силу;

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

За 16 спринтов суммарное число человеко-дней в спринте у нас менялось от 94 до 211, больше чем в два раза. Скорость команды при этом почти не менялась, менялась её ёмкость. Именно это тимлиды обычно и не закладывают.

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

Главная идея: считать не «SP за спринт», а «SP за эффективный человеко-день».

Для каждого человека в каждом спринте считаются эффективные дни:

эффективные дни = (рабочие дни по производственному календарю
                   − отпуска и больничные
                   + переработки)
                  × коэффициент отдачи

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

Коэффициент отдачи — это доля от 0 до 100%. У новичка в первые месяцы он может быть 50–60%, у опытного сотрудника 100%. Это грубая оценка, но без неё каждый приход нового человека ломает прогноз.

Дальше всё просто:

темп = Σ (SP без аврала) / Σ эффективных дней   за последние 6 закрытых спринтов
прогноз = темп × эффективные дни будущего спринта

Темп у нашей команды держится в районе 1,4–2,2 SP на эффективный человеко-день. Шесть спринтов в окне — компромисс: окно достаточно длинное, чтобы сгладить случайности, и достаточно короткое, чтобы учитывать изменения в команде.

Overrun: вычитаем аврал

Самое неочевидное, к чему я пришёл, — фактические SP нельзя напрямую использовать для прогноза.

Представьте: вся команда последние три дня сидела до ночи и дотащила 60 SP. Формально спринт выполнен. Но если положить эти 60 SP в статистику, темп вырастет, следующий план станет больше, и следующий спринт снова закончится кранчем. Получается замкнутый круг, где аврал становится нормой.

Поэтому для каждого закрытого спринта я записываю отдельное число, Overrun:

• положительное, если столько SP сделали с опозданием или в аврале (из примера выше — 60);

• отрицательное, если спринт закончили раньше и команда могла взять ещё столько-то.

В расчёт темпа идёт «факт минус Overrun». Так прогноз отражает темп, который команда держит без переработок.

Учёт времени — обязательное условие

Всё это работает, только если каждый в команде записывает, сколько времени он потратил на какие задачи. Без этого нет ни честного факта, ни понимания, куда ушло время.

Инструмент не важен. Я сам пользуюсь Dayflow на маке: он потом показывает, в какое время я чем занимался. У ребят свои способы. Хватает и обычных записей в заметках, но это требует дисциплины.

Побочный эффект учёта: становится понятно, сколько в среднем стоит 1 SP в часах. Но на оценку в часах мы при этом не переходим. В story points по Фибоначчи можно и нужно оценивать грубо, и у разработчика нет ответственности «не уложился в часы». Часы нужны для понимания, а не для оценки.

Промахи в оценках — это нормально

Примерно 20–30% задач не попадают в оценку. Это нормально, и чаще всего промахи компенсируют друг друга: где-то переоценили, где-то недооценили.

Если задача всё-таки разрастается, мы не растягиваем спринт. Работаем по принципу FFF: время и ресурсы фиксированы, гибкий только объём функциональности. Если что-то не влезло в оценку, это откладывается на будущее, но задача в целом выполняется и уходит в релиз рабочей.

Отсюда и важное ограничение метода. У нас строгая культура: в спринте закрывают 100% задач, «лишних» задач нет, ничего не переносится. Даже если задача по ходу обросла новым контекстом, мы релизим что-то рабочее в срок, а дальше новый спринт и новые планы. Если в вашей команде задачи регулярно переезжают из спринта в спринт, прогноз будет шуметь сильнее.

Поддержка — это выделенное время, а не резерв

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

Сейчас у нас так:

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

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

Насколько это точно: цифры за 16 спринтов

Ниже — сравнение прогноза с фактом за 16 спринтов подряд.

• На длинной дистанции прогноз консервативен. Сумма прогнозов — 3587 SP, сумма факта — 4130 SP. Команда сделала примерно на 15% больше, чем прогнозировалось. В 13 спринтах из 16 факт был не ниже прогноза.

• В отдельном спринте типичная ошибка — около ±18% (медиана по модулю).

• Выбросы бывают. В одном спринте факт оказался на 47% ниже прогноза, а в следующем на 57% выше. Это одна история: спринт закрыли за два дня до релиза, часть задач не успели, они переехали в следующий спринт и раздули его. Вместе эти два спринта дали +21% к прогнозу, то есть на средних цифрах это почти не сказалось.

То, что прогноз немного занижен, меня устраивает. Лучше пообещать меньше и сделать больше, чем наоборот.

Как теперь выглядят разговоры с руководством

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

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

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

• коэффициент настойчивости — насколько заказчик склонен сразу эскалировать или дёргать, пока не сделаешь;

• коэффициент доверия к заказчику — насколько он склонен преувеличивать важность своих задач.

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

Когда таблицы перестало хватать

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

Поэтому я написал отдельный сервис. В нём:

• команда по ролям, у каждого человека даты выхода и ухода и коэффициент отдачи;

• отпуска, больничные и переработки с учётом производственного календаря;

• прогноз по каждой роли по формуле выше, с расшифровкой, откуда взялось каждое число;

• выделенное время на поддержку;

• эпики, отсортированные по важности, с зависимостями и автоматической раскладкой по спринтам;

• предупреждение, если эпик не успевает к дедлайну;

• диаграмма Ганта, которую можно отправить руководству ссылкой.

Так выглядит план: эпики по важности сверху вниз, под ними загрузка каждой роли по спринтам.

А так — расшифровка загрузки одной роли в одном спринте: сколько зарезервировано под поддержку и какие задачи из каких эпиков туда попали.

Кому это не подойдёт

• Командам, где задачи регулярно переносятся из спринта в спринт и нет культуры «закрываем всё».

• Командам без оценок в story points или с сильной инфляцией SP. Сначала придётся вернуть оценкам смысл.

• Командам, где никто не учитывает время. Без факта считать нечего.

• Командам, где состав меняется каждый месяц. Окну в 6 спринтов нужна хоть какая-то стабильность.

Что попробовать у себя, даже без инструмента

1. Начните записывать по каждому спринту факт в SP и число эффективных человеко-дней с учётом отпусков.

2. Отдельно записывайте, сколько SP сделано в аврале, и не учитывайте их в темпе.

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

4. Через 4–6 спринтов считайте прогноз как «темп × эффективные дни» и сравнивайте с фактом.

Всё это делается в обычной таблице, мне она служила долго.

Сервис пока сыроват для чужих команд: он вырос под мою модель работы, и начать в нём с нуля может быть непросто. Но если хотите попробовать или обсудить метод, напишите, дам доступ.