Planning Poker

Что такое Planning Poker

Planning Poker (Scrum Poker) — техника оценки сложности задач, разработанная Джеймсом Гренингом в 2002 году. Каждый член команды тайно выбирает карточку с оценкой, все одновременно показывают. Цель — собрать независимые мнения, избежать эффекта якоря, найти точки расхождения для обсуждения.

Главный инсайт: разные оценки — это не проблема, это информация. Если кто-то поставил 13, а кто-то 3, значит они видят задачу по-разному. Обсуждение раскрывает: один знает о подводном камне, второй — нет. Без обсуждения команда стартанула бы задачу с заниженной оценкой и сорвала бы спринт.

5 колод

• Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89). Классика. Намеренные разрывы между крупными числами заставляют команду выбирать. Используется в 90% Scrum-команд.
• Modified Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). Расширенная: 0.5 для микро-задач, 100 для «слон, нужно разбить». Подходит командам с большим разбросом размеров задач.
• T-shirt sizes (XS, S, M, L, XL, XXL). Для нечисловых команд: маркетинг, дизайн, контент, поддержка. Грубее Fibonacci, но проще для людей не-инженеров.
• Powers of 2 (1, 2, 4, 8, 16, 32, 64). Экспериментальная: каждое число вдвое больше предыдущего. Чёткое удвоение помогает сравнивать «эта задача в 4 раза сложнее той».
• Linear (1-10). НЕ для оценки сложности, для оценки приоритета или риска. Например, «насколько критичен этот баг» (10 = блокер). Не используйте для story points.

Planning Poker is not about getting the right answer. It's about discovering when the team disagrees, and using that disagreement to learn.— James Grenning, изобретатель Planning Poker, 2002

Процесс оценки

1. Прочитать user story. Product Owner объясняет задачу, отвечает на вопросы. 5-10 минут на задачу.
2. Голосование. Каждый ВЫБИРАЕТ карточку, не показывает её. Если используете онлайн-инструмент — каждый «нажимает» свою карту.
3. Раскрытие. Одновременно показываете все карты. Видны расхождения.
4. Обсуждение разногласий. Спрашивают того, кто поставил минимум: «почему ты считаешь, что это легко?». Спрашивают того, кто поставил максимум: «что я упускаю?». 2-3 минуты обсуждения.
5. Повторное голосование. Разрешается уточнить оценку с учётом услышанного. Обычно 2-3 раунда — и есть consensus.
6. Финальная оценка. Если consensus — берём её. Если разброс остался (3, 5, 8, 13) — берём медиану или ближайшее Fibonacci-число к медиане.
7. Что делать с очень большими оценками. Если выпало 21+ или 100 — задачу нужно разбить, не делать в рамках спринта. Спросите Product Owner: «можем ли мы разбить?».

Сигналы для команды

• Все оценили одинаково. Consensus — задача понятна, переходим к следующей. Если consensus у всех — это подозрительно, может быть groupthink. Раз в 5-10 задач делайте чаще обсуждение.
• Разброс маленький (3, 5). Норма. Берите медиану или большее число (быть пессимистом полезно).
• Разброс огромный (3, 13, 21). Команда видит задачу по-разному. ОБЯЗАТЕЛЬНО обсудите. Часто — задача описана плохо, требует уточнения.
• «?» — не знаю. Задача не готова к оценке. Положите в «refine later».
• «☕» — кофе. Перерыв 10 минут, фокус упал.
• Один человек выпадает. Если 4 поставили 5, а один 21 — спросите его. Возможно он знает то, что другие не знают (риск).

Подводные камни

• Story points ≠ часы. Не пытайтесь сконвертировать. Команда A делает 30 SP за спринт, команда B — 50. Это нормально, шкалы разные.
• Сильный участник доминирует. Если в команде есть techlead, у которого все спрашивают мнения — Planning Poker этого не лечит. Нужна работа над культурой.
• Junior боится показать незнание. Поставит «как у всех». Менеджер должен поощрять разные мнения, не наказывать «низкие» оценки.
• Тратьте 10-15 минут на задачу. Если оценка занимает 30+ минут — задача описана плохо. Возвращайте Product Owner на refinement.
• Не оценивайте в спринте. Это для backlog refinement (отдельное событие). В планировании уже есть оценки, выбираете задачи под velocity.