Planning poker, story points, t-shirt sizes, affinity estimation
Время освоения: ~40 минут
| Метод | Когда использовать | Шкала | Скорость |
|---|---|---|---|
| Story Points | Основная оценка в Scrum | Фибоначчи: 1, 2, 3, 5, 8, 13, 21 | Средняя |
| T-Shirt Sizing | Ранние этапы, эпики, быстрая оценка | XS, S, M, L, XL | Быстрая |
| Planning Poker | Консенсус команды по конкретной истории | Фибоначчи (карточки) | Медленная, зато точная |
| Affinity | Много задач сразу (50+) | По группам сложности | Очень быстрая |
| Three-Point | Высокая неопределённость | O, M, P → формула | Медленная |
Story Points = Effort (усилие) + Risk (риск) + Uncertainty (неопределённость)
Не часы! Относительная мера сложности относительно базовой истории.
| Шаг | Действие |
|---|---|
| 1 | PO представляет историю |
| 2 | Команда задаёт вопросы |
| 3 | Каждый выбирает карточку втайне |
| 4 | Все показывают одновременно |
| 5 | Обсуждение крайних значений |
| 6 | Повторная оценка до консенсуса |
Оценка = (Optimistic + 4 × Most Likely + Pessimistic) ÷ 6
Пример: (2 + 4×4 + 8) ÷ 6 = 4.3 дня
| Ошибка | Последствие |
|---|---|
| Оценка в часах | Давление на команду, иллюзия точности |
| Только техлид оценивает | Нет командного понимания |
| Velocity = KPI разработчика | Команда накручивает числа |
| Не пересматривают оценки | Устаревшие данные, плохой прогноз |
Оценка в Agile — это не предсказание точного времени выполнения, а инструмент принятия решений для планирования и управления рисками.
💡 Ключевая мысль: В Agile мы оцениваем сложность (effort + risk + uncertainty), а не время. Цель — получить относительную оценку для принятия решений, а не абсолютную точность.
Что это: Относительная оценка сложности задачи Как работает:
Преимущества:
Что это: Оценка в человеко-часах или днях Когда использовать:
Риски:
Что это: Быстрая оценка: S, M, L, XL Когда использовать:
Преимущества: Быстро, интуитивно, хорошо для приоритизации
Что это: Каждый участник дает определенное количество точек для приоритизации Как работает:
Использование: Приоритизация Product Backlog, совместное принятие решений
Процесс:
Правила:
Процесс:
Преимущества: Быстро для большого количества задач, хорошо для новых команд
Формула: (Optimistic + 4 × Most Likely + Pessimistic) / 6 Когда использовать: Для задач с высокой неопределенностью Пример:
Ситуация: Команда оценивает в часах, планирует 160 часов на 2-недельный спринт, но выполняет только 120 часов.
Анализ:
Решение:
Ситуация: Новый разработчик говорит: "Почему эта задача 8 баллов, а эта 13? Я бы сделал за 2 дня!"
Подход:
| Ошибка | Последствия | Как избежать |
|---|---|---|
| Оценка в часах для всего | Иллюзия точности, давление на команду | Использовать story points для большинства задач |
| Оценка только техлидом | Нет командного консенсуса | Вовлекать всю команду в оценку |
| Не пересматривать оценки | Устаревшие данные, плохой прогноз | Регулярный refinement и адаптация |
| Связывать оценку с производительностью | Команда занижает оценки | Разделить оценку (planning) и производительность (velocity) |
Что это: Когда оценка превращается в показательное мероприятие для руководства без реальной пользы и улучшения процессов.
Примеры:
Результат: Потеря ценности оценки, неточное планирование, снижение мотивации команды.
Как избежать:
Что это: Когда оценка становится препятствием для работы вместо помощи в планировании, отнимая время без реальной пользы.
Примеры:
Решение:
⚠️ Важно: Оценка должна помогать команде принимать решения, а не становиться барьером для работы. Если процесс оценки отнимает больше времени, чем приносит пользы — его нужно упростить или заменить.
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| Velocity команды A сравнивают с командой B | Шкалы story points уникальны для каждой команды, сравнение бессмысленно | Velocity — только для внутреннего прогнозирования конкретной команды |
| Оценивает только техлид, команда молчит | Команда не понимает задачи, теряется скрытое знание | Planning Poker: все показывают карточки одновременно |
| Story points = часы в маскировке | Давление «ты взял 8 points = 8 часов», качество падает | Объяснить: SP = сложность × риск × неопределённость, не время |
| Базовая история меняется между спринтами | Velocity несравнимый, прогнозирование ломается | Зафиксировать эталонную историю, не менять её минимум 2–3 месяца |
| Planning Poker проводят формально, «лишь бы быстрее» | Оценки не отражают реальной сложности, блокировки во время спринта | Обязательно обсуждать крайние значения — там скрыто важное знание |
| Оценку используют для создания плана на квартал «в часах» | Иллюзия точности, контракт вместо прогноза | Roadmap в диапазонах: «6–9 спринтов», не «48 дней» |
Преобразуйте оценки в story points (используя Фибоначчи):
Подсказка: Базовая история = 5 баллов
У вас есть задача: "Интеграция с платежной системой"
Команда дала оценки: 3, 5, 8, 13, 21
Ваша задача:
🎯 Главный вывод: Хорошая оценка в Agile — это не точность, а качество принятия решений. Цель — помочь команде лучше планировать и управлять рисками, а не предсказать будущее с точностью до часа.
Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.