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

Планирование спринтов на последнем месте работы

В последней компании мы использовали 2-недельные спринты с чётко структурированным процессом планирования, который я активно координировал как бизнес-аналитик.

Структура процесса планирования

1. Подготовка бэклога (за 3-4 дня до спринта)

• Я проводил сессии уточнения требований с продакт-менеджерами и стейкхолдерами
• Каждая история пользователя (user story) содержала:
  • Описание функции с деталями
  • Критерии приёмки
  • Оценку сложности (Story Points)
  • Зависимости от других задач

2. Встреча планирования спринта (3 часа, начало спринта)

Процесс следующий:

• Обзор целей — продакт озвучивает приоритеты на спринт (15 минут)
• Обсуждение историй — разработчики, дизайнеры и я уточняем требования (90 минут)
• Оценка — команда использует Poker Planning для определения Story Points
• Коммитмент — команда берёт на себя обязательства по объёму работ (15 минут)

Инструменты и метрики

Мы использовали Jira для управления спринтами:

• Velocity — среднее количество Story Points за спринт (~45-50 points)
• Burn-down chart — отслеживали прогресс в течение спринта
• Capacity planning — учитывали отпуска, больничные, внеплановые задачи

Мой вклад как аналитика

1. Рефайнмент бэклога — я переписывал требования так, чтобы они были понятны разработчикам
2. Модерирование дискуссий — направлял беседу в нужное русло, избегал оффтопа
3. Определение приёмки — формулировал чёткие критерии успеха
4. Risk assessment — указывал на потенциальные проблемы и блокеры

Результаты

• Предсказуемость — velocity стабилизировалась, что позволило планировать релизы
• Качество — меньше переделок благодаря чётким требованиям
• Мотивация команды — процесс был справедливым и прозрачным
• Скорость доставки — за 6 месяцев мы увеличили скорость на 30%

Основной урок

Качество планирования спринта зависит от качества подготовки. Если бэклог хорошо уточнен и структурирован, встреча планирования проходит быстро и эффективно.