Как из оценки задач понять сколько их поместится в спринт?

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

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

Шаг 1: Сбор и стандартизация оценок

Во-первых, оценка задач должна быть консистентной. Мы используем Story Points (SP) по шкале Фибоначчи (1, 2, 3, 5, 8, 13...), которые отражают сложность, риски и объём работ, а не идеальные часы.

Пример оценок во время планирования:
- "Добавить кнопку экспорта" = 3 SP (знакомая задача)
- "Интегрировать с новым платежным шлюзом" = 8 SP (есть неопределённости)
- "Исправить критический баг в расчётах" = 2 SP (срочно, но объём ясен)

Перед планированием проверяю, что:

• Все задачи оценены всей командой (например, через Planning Poker).
• Критерии готовности (Definition of Done) едины для всех оценок.
• Крупные задачи (13+ SP) разбиты на более мелкие.

Шаг 2: Анализ исторической пропускной способности (Velocity)

Это — основа прогноза. Velocity — это среднее количество Story Points, которое команда стабильно завершает в спринте за последние 3-6 итераций. Рассчитываю как:

# Пример расчёта velocity за последние 4 спринта
completed_points_per_sprint = [32, 28, 35, 30]
average_velocity = sum(completed_points_per_sprint) / len(completed_points_per_sprint)
# average_velocity = 31.25 SP

Важно: Использую median или устойчивое среднее, чтобы нивелировать выбросы (например, спринт с авралом). Из данных выше, я бы взял плановый velocity ≈ 31 SP.

Шаг 3: Учёт факторов ёмкости и неопределённости

Просто сравнить список оцененных задач с velocity недостаточно. Для реалистичного плана ввожу поправочные коэффициенты:

1. Учёт доступности команды (Capacity Planning):

    * Рассчитываю идеальное время команды в человеко-днях.
    * Вычитаю плановые отпуска, больничные, обучение, митинги.
    * Например, если 20% времени уйдёт на непрямые работы, то ёмкость спринта = 0.8 * velocity.

1. Резерв на неопределённость и баги:

    * Всегда резервирую 15-20% ёмкости спринта на незапланированные работы, срочные фиксы или уточнение уже взятых задач.
    * Если velocity = 31 SP, то на запланированные фичи планирую не более 25 SP.

1. Баланс типов работ:

    * Стараюсь включать микс из новой функциональности, техдолга и багов, чтобы избежать перекоса.

Шаг 4: Процесс согласования и фиксации плана

На Sprint Planning Meeting вместе с командой:

• Выбираем задачи из беклога продукта, начиная с наивысшего приоритета.
• Суммируем их оценку, пока не приблизимся к скорректированной ёмкости (например, 25 SP).
• Ключевой момент: Команда финально соглашается, что все выбранные задачи реалистичны и они берут на себя ответственность за их выполнение. Это не просто математика, а коллективное обязательство.

Итоговый план спринта:
1. Задача А (5 SP)
2. Задача Б (8 SP)
3. Задача В (5 SP)
4. Задача Г (3 SP)
5. Техдолг (2 SP)
6. Резерв на незапланированное (~4 SP)
---
Сумма оценок запланированного: 23 SP
Общая ёмкость спринта: ~27 SP

Шаг 5: Мониторинг и обратная связь

После утверждения плана:

• Разбиваю крупные задачи на более мелкие технические подзадачи (в часах) для ежедневного отслеживания.
• На Daily Scrum слежу, не уходит ли выполнение задач за рамки их изначальной оценки.
• Если появляются серьёзные отклонения, мы как команда решаем: уточнить/переоценить задачу, вынести её из спринта или скорректировать scope.

По итогам спринта на Retrospective обязательно анализируем:

• Насколько наши оценки были точны.
• Почему могли возникнуть расхождения (недостаточный анализ, внешние блокеры, interruptions).
• Как улучшить процесс оценки и планирования для следующих итераций.

Итог: Понимание того, сколько задач поместится в спринт, — это не просто арифметика "оценки vs velocity". Это комбинированный процесс, где данные (исторический velocity) сопоставляются с текущим контекстом (ёмкостью, рисками) и завершаются коллективным соглашением команды. Точность приходит с опытом и постоянной калибровкой на основе фактов завершённых работ. Главная цель — сформировать реалистичный, мотивирующий план, который команда сможет с высокой вероятностью выполнить, тем самым поддерживая устойчивый ритм и предсказуемость проекта.