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

Процесс планирования спринта: от Backlog к Sprint Backlog

Планирование того, какие задачи попадут в спринт (Sprint Planning) – это ключевой событие Scrum, где команда совместно определяет объем работы. Основанием всегда служит Приоритизированный Бэклог Продукта (Product Backlog), сформированный и поддерживаемый Владельцем Продукта (Product Owner). Вот как выглядит типичный процесс.

Ключевые входные данные (Inputs)

На вход поступает уже подготовленный бэклог. Хорошая практика – провести его рефинимент (Backlog Refinement) до планирования, чтобы:

• Задачи были ясными, понятными и разделенными (принцип INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable).
• Были даны предварительные оценки (часто в стори поинтах или часах).
• Определены зависимости и риски.
• Команда понимала бизнес-ценность каждой задачи (User Story).

Пример структурированной User Story в бэклоге:

**Как [роль пользователя], я хочу [возможность], чтобы [получаемая ценность].**

Критерии приемки (Acceptance Criteria):
*   AC1: При нажатии кнопки "Сохранить" данные валидируются.
*   AC2: При успешном сохранении появляется уведомление.
*   AC3: В случае ошибки валидации отображаются конкретные сообщения.

Оценка: 5 стори поинтов

Механика процесса планирования спринта

Процесс обычно состоит из двух частей:

1. Часть 1: «ЧТО?» (What) – Владелец Продукта представляет команде цель спринта (Sprint Goal) и наиболее приоритетные элементы бэклога, которые могут ее достичь.
2. Часть 2: «КАК?» (How) – Команда разработки (включая тестировщиков, дизайнеров) декомпозирует выбранные элементы на конкретные технические задачи, оценивает их и принимает окончательное решение об объеме.

Решающим критерием является не желание Владельца Продукта, а реальная пропускная способность команды (Capacity/ Velocity).

Четыре основных ограничивающих фактора

На практике решение принимается на пересечении следующих факторов:

• Пропускная способность команды (Team Capacity): Рассчитывается с учетом отпусков, больничных, внутренних совещаний и известной исторической скорости (Velocity). Это «бюджет» спринта.

  # Пример упрощенного расчета capacity (в идеальных часах)
  team_members = 5
  sprint_days = 10
  hours_per_day_per_member = 6  # Учет встреч, перерывов
  capacity_total = team_members * sprint_days * hours_per_day_per_member
  # capacity_total = 300 часов
  

• Технические зависимости и долг: Задачи могут блокироваться незавершенной инфраструктурой, интеграциями или необходимостью сначала решить проблемы технического долга.

• Приоритет и ценность (Business Value): Задачи с высшим приоритетом от Владельца Продукта рассматриваются в первую очередь. Sprint Goal служит фильтром – задачи должны ему соответствовать.

• Готовность задачи к работе (Definition of Ready - DoR): Задача должна соответствовать заранее согласованным критериям готовности (например, «есть дизайн», «описаны критерии приемки», «понятны бизнес-требования»), чтобы команда могла взять ее в работу без простоев.

Роль Project Manager / Scrum Master

Как фасилитатор этого процесса, я слежу за тем, чтобы:

• Дискуссия была конструктивной и все члены команды были услышаны.
• Оценки были реалистичными, а не оптимистичными. Используем Planning Poker или метод аналогий.
• Команда сама брала на себя обязательства, а не получала их сверху. Это ключ к мотивации и ответственности.
• Итогом сессии был четкий Sprint Backlog с понятными задачами, распределенными между участниками, и видимым инкрементом на конец спринта.

Итоговый критерий: Sprint Goal

Главный результат планирования – не просто список задач, а Sprint Goal. Именно под него отбираются задачи. Если задача напрямую не ведет к достижению цели спринта – это серьезный повод пересмотреть ее включение.

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