Agile Estimation

Оценка = (Optimistic + 4 × Most Likely + Pessimistic) ÷ 6
Пример: (2 + 4×4 + 8) ÷ 6 = 4.3 дня

• Прогнозирование: Сколько работы можно сделать за спринт/релиз
• Приоритизация: Сравнение сложности задач для выбора наиболее ценных
• Управление рисками: Выявление неопределенности и сложных элементов
• Согласование ожиданий: Общее понимание объема работы между командой и заинтересованными сторонами

• Человеческая неопределенность: "Я думаю, это займет 2 дня" → на самом деле 5 дней
• Фокус на процессе, а не на результате
• Создает давление и мотивацию "выполнить план", а не "доставить ценность"
• Не учитывает риски и неопределенность

💡 Ключевая мысль: В Agile мы оцениваем сложность (effort + risk + uncertainty), а не время. Цель — получить относительную оценку для принятия решений, а не абсолютную точность.

• Базовая история = 5 баллов (или 8, или другое число)
• Новые истории сравниваются с базовой
• Используется последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21...

• Учитывает неопределенность (разница между 8 и 13 больше, чем между 1 и 2)
• Фокус на сложности, а не на времени
• Командная оценка через консенсус

• Для очень маленьких задач (< 4 часов)
• Когда требуется точное планирование (например, для внешних контрактов)
• В комбинации со story points для уточнения

• Создает иллюзию точности
• Приводит к давлению на команду
• Не учитывает неопределенность

• На ранних этапах продукта
• Для высокого уровня планирования (epics, themes)
• При работе с новыми командами

• Участники получают N точек (например, 5)
• Распределяют точки между задачами
• Задачи с наибольшим количеством точек — самые приоритетные

1. PO представляет пользовательскую историю
2. Команда обсуждает детали и критерии приемки
3. Каждый участник выбирает карточку с оценкой (Фибоначчи)
4. Все показывают карточки одновременно
5. Если есть расхождения — обсуждение и повторная оценка
6. Повторять до достижения консенсуса

• Никто не говорит свою оценку вслух до показа
• Обсуждение только после показа всех карточек
• Фокус на "почему" разные оценки, а не на "кто прав"

1. Написать все задачи на карточки
2. Выбрать 3-5 базовых задач с известной сложностью
3. Команда группирует остальные задачи по сходству с базовыми
4. Присваивает оценки по группам

• Optimistic: 2 дня
• Most Likely: 4 дня
• Pessimistic: 8 дней
• Результат: (2 + 4×4 + 8) / 6 = 4.3 дня

• Оценка в часах не учитывает неопределенность
• Нет buffer для непредвиденных задач
• Команда фокусируется на "выполнении плана", а не на "доставке ценности"

1. Перейти на story points
2. Использовать velocity для прогнозирования (не для оценки производительности)
3. Добавить buffer для неопределенных задач
4. Фокусироваться на завершенных задачах, а не на затраченном времени

1. Объяснить разницу между сложностью и временем
2. Показать примеры: 8 баллов = много неизвестных, 13 баллов = высокий риск + сложная интеграция
3. Вовлечь нового участника в процесс оценки
4. Использовать технику "обучения через практику"

• Команда ставит одинаковые оценки для всех задач, чтобы выглядеть предсказуемой
• Оценка проводится только для отчетности, а не для планирования
• Участники не участвуют активно, а просто выполняют формальности

• Сфокусироваться на ценности процесса, а не на форме
• Регулярно собирать обратную связь от команды о полезности оценки
• Адаптировать процесс под нужды конкретной команды

• Слишком долгие сессии оценки, которые отнимают время от разработки
• Команда боится давать реалистичные оценки из-за страха критики
• Формальные процессы, которые мешают быстрой адаптации

• Регулярная оценка ценности процесса оценки
• Адаптация длительности и формата сессий под нужды команды
• Создание психологически безопасной среды для честных оценок

⚠️ Важно: Оценка должна помогать команде принимать решения, а не становиться барьером для работы. Если процесс оценки отнимает больше времени, чем приносит пользы — его нужно упростить или заменить.

1. "Эта задача примерно как базовая история" → ?
2. "Вдвое сложнее базовой" → ?
3. "Много неизвестных, высокий риск" → ?
4. "Простая, знакомая задача" → ?

1. Что может объяснять такой разброс?
2. Как вы бы провели обсуждение для достижения консенсуса?
3. Какая оценка наиболее вероятна и почему?

1. В чем основное отличие story points от оценки в часах?
2. Почему используется последовательность Фибоначчи для story points?
3. Что такое velocity и как его использовать правильно?
4. Какие три компонента входят в story points (effort + ? + ?)?
5. Почему нельзя связывать оценку с производительностью команды?

• Книга: "Agile Estimating and Planning" — Mike Cohn
• Статья: "Story Points vs Hours" — Mountain Goat Software
• Инструменты: PlanningPoker.com, Jira (встроенная оценка), Miro для онлайн-сессий
• Практика: Проведите Planning Poker с реальными задачами вашей команды

🎯 Главный вывод: Хорошая оценка в Agile — это не точность, а качество принятия решений. Цель — помочь команде лучше планировать и управлять рисками, а не предсказать будущее с точностью до часа.