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

Решение

1. Проведение ретроспективы

Подготовка (до встречи)

Шаг 1: Данные

• Собрать фактические метрики спринтов:
  • Взяли story points: 50, закрыли: 30 (2 спринта подряд)
  • Какие задачи не закрылись? (список)
  • Когда они заблокировались? (день 1? день 7?)
  • Кто работал на каких задачах? (распределение)
  • Было ли sick leave, отпуск, срочные работы?
• Метрики качества:
  • Сколько bugs найдено на QA по каждой задаче?
  • Сколько задач отправлено back на разработку?
  • Сколько переделок?
• История эстимейтов:
  • Как менялись story points:

    - Задача оценена на 8SP, закрыта на 13SP, занял 16 часов
    - Задача оценена на 5SP, закрыта на 2 часа

• Есть ли систематическое underestimation?

Шаг 2: Гипотезы

Перед встречей составить гипотезы:

• Гипотеза 1: задачи оцениваются неправильно (слишком оптимистично)
• Гипотеза 2: много неожиданной работы (support, bugs в production)
• Гипотеза 3: блокеры и зависимости (ждём других, infrastructure issues)
• Гипотеза 4: качество: разработка сдаёт с багами, QA находит и отправляет back
• Гипотеза 5: процесс: context switching, meetings, прерывания
• Гипотеза 6: люди: болезни, отпуск, низкая мотивация

Формат ретроспективы

Участники: вся team (разработка, QA, PM), NO руководство

• Причина: люди будут боятся говорить правду если boss на встречи
• Ruководство узнает результаты после

Длительность: 90 минут (не дольше)

Структура:

1. Intro (5 мин)

• Цель: понять почему не вписались, как улучшить
• Ground rules: "Это не blame meeting. Мы ищем проблемы в процессе, не в людях"
• Tone: collaborative, не defensive

2. What went wrong (20 мин)

Метод: Brainstorm на доске

• Каждый говорит что пошло не так
  • Dev: "Задачи оцениваются слишком оптимистично"
  • QA: "Много багов, переделки занимают время"
  • Dev: "Был срочный production bug, отвлекал на 1-2 дня"
  • PM: "Scope меняли в середине спринта"
• Все идеи на доску
• НЕ критиковать, НЕ защищаться, просто собрать

3. Анализ корневых причин (30 мин)

Метод: 5 Whys

"Почему мы не вписались в спринт?"

• "Потому что задачи оцениваются слишком низко"
• "Почему задачи оцениваются низко?"
  • "Потому что мы не видим все requirements в начале спринта"
  • "Потому что новый рабочий не знает кодовую базу, берёт дольше"
  • "Потому что нет буфера на QA переделки"

"Почему много багов сдаётся на QA?"

• "Потому что нет time для тестирования разработчиком"
• "Потому что requirements неясны, разработка интерпретирует по-своему"
• "Потому что спешим, не думаем об edge cases"

4. Grouping (15 мин)

Сгруппировать найденные причины:

• Estimation issues (недооценка требований)

  • Неясные requirements
  • Новые люди недооценивают
  • Нет буфера на QA
  • History data неиспользуется

• Quality issues (много переделок)

  • Нет dev-level testing
  • Неясные requirements
  • Недостаточно code review
  • Edge cases не продуманы

• Process issues (scope creep, meetings, interrupts)

  • Scope меняется в спринте
  • Много production support
  • Много внеплановых meetings

• Knowledge issues (новые люди, context switching)

  • Джуниоры берут дольше
  • Context switching (проект 1 -> проект 2)
  • Документация неполная

• Resource issues (болезни, отпуск)

  • Неожиданные отсутствия
  • Burnout

5. Action items (20 мин)

Для КАЖДОЙ критичной причины: action item

Пример:

Проблема: Задачи underestimated
Причина: Requirements неясны на planning
Action: 
  - PM проводит grooming session за день до спринта (3 часа)
  - На grooming: все questions обсуждаются, requirements clarify
  - Estimate пересчитывается если нужно
  - Ответственный: PM
  - Дедлайн: sprint planning на день позже

Проблема: Много bugs от разработки на QA
Причина: Разработчик не тестирует должным образом
Action:
  - Каждая задача: 10-15% времени на dev-level testing
  - Чек-лист перед "Done": основные scenarios пройдены, edge cases?
  - Code review: требует attention к edge cases
  - Ответственный: Lead dev
  - Дедлайн: next sprint

Проблема: Scope creep
Причина: Клиент просит добавить features в спринте
Action:
  - Спринт scope = locked. Новые requests -> backlog
  - Исключение: critical production bugs только
  - PM объяснить клиенту на kickoff
  - Ответственный: PM
  - Дедлайн: before next sprint

6. Commitments (5 мин)

• Каждый action item: владелец, дедлайн
• Кто что внесёт в next sprint?
• Обещания вслух в группе (psychological commitment)

7. Closing

• Спасибо за честность и участие
• Next retro: через спринт (чтобы видеть изменения)
• Результаты send в письме

2. Изменения в процессе планирования

Проблема 1: Требования неясны на planning

Решение: Grooming/Refinement сессия

Что это:

• За 1-2 дня до sprint planning: отдельная сессия
• Участники: PM, lead dev, senior разработчик, QA lead
• Agenda: детализировать все stories для next sprint

Процесс:

1. PM показывает story
2. "Какие questions у вас есть?"
3. Обсуждение: acceptance criteria, edge cases, dependencies
4. Уточнения записываются
5. Initial estimate (если ещё не было) или пересчет

Результат:

• Requirement clear
• Estimate более точный
• На sprint planning нет вопросов, только finalization

Время: 1-2 часа на 40 story points работы

Проблема 2: История эстимейтов не используется

Решение: Velocity tracking и historical data

Что это:

• Вести историю: на сколько оцена, на сколько заняла, почему расхождение

Таблица (Confluence/Jira):

Task | Initial SP | Actual SP | Actual hours | Diff | Reason
Auth | 8 | 13 | 21 | +5 | Забыли про OAuth
API | 5 | 5 | 8 | 0 | Good estimate
UI | 5 | 8 | 13 | +3 | Больше edge cases

Анализ:

• Каждый спринт: average velocity

  • Взяли 50 SP, закрыли 30 SP -> velocity 30/50 = 60%
  • Или: в hours: взяли 80 часов, занял 130 часов -> ratio 130/80 = 1.62x

• Тренды:

  • "Мы систематически берём 50, закрываем 30"
  • "Разработка consistently underestimates на 20-30%"
  • "QA переделки это 15% от времени"

Action:

• Добавить buffer в планирование
  • Если velocity 60%, берём 50 вместо 80 (более реалистично)
  • Если QA переделки это 15%, зарезервировать 15% time
  • Если джуниоры работают: multiplier 1.5x на их estimates

Проблема 3: Scope меняется в спринте

Решение: Freeze на scope, emergency protocol

Правило:

• Sprint = locked. Требования не меняются.
• Исключение: critical production bugs (данные теряются, security issue, revenue lost)
• Новые requests -> backlog -> следующий спринт

Emergency protocol:

• Если critical issue: PM, lead dev, client обсуждают
• Если в спринт вносится: что убираем из спринта (чтобы velocity не сломалась)
• Документируем: "Спринт 5: взяли 50 SP + 8 SP emergency, убрали 8 SP scope creep"

Коммуникация клиента:

• Sprint kickoff: "На этот спринт взяли XYZ features. Другие feature requests пойдут в backlog на next sprint"
• Ясно, что переделить нельзя

Проблема 4: Production support отвлекает

Решение: Dedicated support person + buffer

Что это:

• 1 разработчик (ротация): support на sprint
• Остальные: только на новые features

Time allocation:

• Без support duty: 100% на новые features
• На support duty: 60% support, 40% новые features
• На sprint planning: team capacity = (4 devs × 100%) + (1 dev × 40%) = 4.4 FTE
• Берём story points соответственно

Результат:

• Support не прерывает плановую работу
• Velocity стабилен
• Можем predict

Проблема 5: QA переделки

Решение: Dev testing + QA criteria

Dev level testing (10-15% времени):

• Dev сам тестирует task перед тем как отправить
• Чек-лист:
  • Happy path работает?
  • Error cases обработаны?
  • Edge cases?
  • UI согласен с design?
  • Performance OK?
  • Security?
• Если задача 8 часов: 1 час на testing, 7 часов на разработку

QA criteria (принятие):

• QA смотрит что:
  • Requirements покрыты
  • Нет obvious bugs
  • Performance OK
  • Не сломана existing functionality
• НЕ смотрит что:
  • Dev не потестировал (это dev responsibility)
  • Obvious bugs (они не должны доходить до QA)

Результат:

• Меньше переделок
• QA time экономится на 20-30%
• Better quality

3. Улучшение точности эстимейтов

Техника 1: Planning Poker

Что это:

• Вместо PM говорит "это 8 SP", используем group consensus

Процесс:

1. PM читает story
2. Каждый dev одновременно пишет оценку (1, 2, 3, 5, 8, 13 SP)
3. Все показывают карточки
4. Если разброс: обсуждение
   • "Зачем ты сказал 13?"
   • "Потому что нужна интеграция с API"
   • "Ах верно, я забыл!"
5. Пересчет

Результат:

• Группа более accurate чем индивидуальные estimates
• Risks выявляются (если someone видит что-то что others not)
• Knowledge sharing

Техника 2: Historical comparison

Что это:

• Сравнивать с прошлыми tasks

Процесс:

1. "Эта задача похожа на... (показать task из прошлого спринта)"
2. "Та была 8 SP, эта должна быть примерно столько же"
3. Adjust если difference

Результат:

• Consistency
• Люди помнят как долго предыдущие похожие tasks

Техника 3: Acceptance Criteria as estimate guide

Что это:

• Acceptance criteria определяют complexity

Правило:

1-2 AC: ~5 SP (простая задача)
3-5 AC: ~8 SP (средняя)
6-10 AC: ~13 SP (большая)
10+ AC: нужно разбить на smaller stories

Техника 4: Buffer for unknowns

Что это:

• "Я знаю как сделать, но есть unknowns"
• Добавить buffer

Правило:

Base estimate: 5 часов
Unknowns risk:
- New technology: +3 часа
- Third-party integration: +2 часа
- Performance optimization: +2 часа
Total: 12 часов (round to 8 SP)

Техника 5: Estimation conversation

Что это:

• Перед estimate: discuss requirements

Conversation:

• PM: "Что нужно для этого?"
• Dev: "Нужно API endpoint, database migration, frontend, tests"
• "Сколько времени на каждое?"
  • API: 3 часа
  • Migration: 1 час
  • Frontend: 4 часа
  • Tests: 2 часа
  • Total: 10 часов (round to 8 SP)

Результат: более детальный анализ

Техника 6: Reduce story size

Что это:

• Большие stories harder to estimate
• 13+ SP -> разбить на smaller

Правило:

13+ SP: break down
Ideal range: 5-8 SP
Too small: <2 SP (combine или remove)

Пример:

• "Implement user authentication" (21 SP) -> break down:
  • "Design auth flow and DB schema" (5 SP)
  • "Implement login/signup endpoints" (8 SP)
  • "Implement JWT tokens" (5 SP)
  • "Add tests" (3 SP)

Техника 7: Velocity tracking and prediction

Что это:

• Использовать velocity для планирования

Расчет:

• Last 3 sprints velocity: 30, 28, 32 SP -> average 30 SP
• Next sprint planning: берём ~30 SP (не 50)

Prediction:

• Backlog: 200 SP
• Velocity: 30 SP/sprint
• Timeline: 200 / 30 = ~7 sprints

Итоговый план на спринт (combining techniques)

День 1 (Backlog grooming):
- PM готовит stories (requirements clear)
- PM estimate initial (rough)
- TBD: список для refinement

День 2-3 (Refinement):
- PM + leads discuss stories
- AC clarified
- Unknowns identified
- Rough estimates adjusted

День 4 (Sprint planning):
- Planning poker для final estimates
- Team commits to velocity based on historical data
- Risks discussed
- Action items identified

День 5 (Sprint start)
- Daily standup
- Track progress
- Adjust if risks materialize

Ранее спринта на 1-2 дня (grooming для NEXT sprint):
- Prepare next sprint stories

Итог

Проблема underfulfillment это не feature разработчиков, это сигнал что planning процесс need improvement. Решение: лучшая коммуникация (grooming), лучшие данные (velocity tracking), буфер для неопределённости (historical ratio), и культура commitment (everyone agrees on realism). Результат: predictable sprints, happy team, happy management.