Planning Poker — это один из самых популярных и эффективных методов для оценки трудоемкости задач (User Stories или элементов Бэклога) в гибких командах. Вместо того чтобы полагаться на мнение одного эксперта, этот метод использует мудрость толпы и игру, чтобы быстро выявить и обсудить те части задачи, которые члены команды понимают по-разному.
Основная цель Planning Poker — не только получить число (оценку в Story Points), но и обеспечить общее понимание задачи, ее сложности, рисков и зависимостей. Это достигается за счет параллельного выставления оценок и последующего обсуждения наибольших разногласий.
Почему используется Последовательность Фибоначчи (1, 2, 3, 5, 8, 13…)
В Planning Poker обычно используется модифицированная последовательность Фибоначчи (1, 2, 3, 5, 8, 13 и т.д.). Почему? Смысл в том, что по мере увеличения размера задачи, неопределенность и риски растут экспоненциально. Большая разница между, например, 8 и 13, заставляет команду быть более осторожной и признать высокую степень неопределенности, что, в свою очередь, стимулирует декомпозицию крупной задачи.
Правила Игры Planning Poker (7 Шагов)
- Фасилитатор: Scrum Master или фасилитатор управляет процессом, но не участвует в оценке.
- Product Owner: PO представляет задачу (User Story), объясняя ее ценность и критерии готовности (DoD).
- Вопросы: Команда обсуждает задачу, задавая вопросы PO.
- Оценка: Когда все вопросы сняты, каждый участник команды разработки одновременно кладет свою карту с оценкой (Story Points) на стол, рубашкой вверх.
- Открытие: Все карты открываются одновременно.
- Обсуждение Разногласий: Если оценки сильно различаются (например, 3 и 13), члены команды, давшие самую низкую и самую высокую оценку, объясняют свое мнение. Это ключевой шаг, поскольку он выявляет невидимые риски или недопонимание.
- Повтор: После обсуждения команда голосует заново, пока не достигнет консенсуса (или пока не останется минимальное расхождение).
| Преимущество | Описание |
| Выявление Рисков (Консенсус) | Одновременное голосование заставляет команду обсуждать самые большие расхождения в оценках, что немедленно выявляет непонятные места или скрытые технические риски. |
| Избегание “Якорного Эффекта” | Члены команды голосуют одновременно, не зная оценок других. Это исключает влияние самого старшего или самого уверенного разработчика (Senior Dev). |
| Вовлеченность и Ответственность | Каждый член команды, независимо от опыта, должен участвовать и защищать свою оценку, что повышает ответственность за результат Спринта. |
| Улучшение Декомпозиции | Если оценка задачи превышает 13 или 20 Story Points, это автоматически сигнализирует о необходимости декомпозиции (разделения) задачи на более мелкие, управляемые части. |
| Прогнозируемость (Velocity) | Более точная оценка задач ведет к более стабильной и предсказуемой Velocity команды, что помогает Product Owner’у точнее планировать релизы. |
Главная ценность Planning Poker заключается в его способности преобразовывать разрозненные, субъективные оценки в общее, коллективное понимание. Когда члены команды, давшие самую высокую и самую низкую оценку, вынуждены публично объяснить свои расхождения, они, по сути, обмениваются скрытыми знаниями: один говорит о невидимом техническом риске, а другой о простоте реализации. Таким образом, Planning Poker становится не просто способом оценки, а высокоэффективным инструментом коммуникации и управления рисками.
Важно помнить, что Story Points — это оценка трудоемкости и сложности, а не чистого времени (часов). Если команда начинает конвертировать баллы в часы, теряется одно из ключевых преимуществ Agile — фокус на относительной сложности. Поэтому фасилитатор (Scrum Master) должен строго следить за тем, чтобы команда использовала последовательность Фибоначчи и обсуждала только причины расхождения, а не пыталась угадать, сколько “часов уйдет на 13 баллов”.
ГЛАВНЫЙ ВЫВОД (РЕЗЮМЕ): Planning Poker — это инструмент для достижения общего понимания, а не просто способ получения числа. Одновременное голосование заставляет каждого члена команды обдумать задачу самостоятельно, а последующее обсуждение разногласий гарантирует, что все скрытые риски и сложности будут вынесены на поверхность до начала работы.
Часто задаваемые вопросы (FAQ)
Если расхождение остается, это явный признак того, что задача недостаточно проработана (не Refined). Вместо того чтобы продолжать бесконечное голосование, Scrum Master должен остановить игру, попросить Product Owner’а взять задачу обратно в Бэклог Продукта для дополнительной декомпозиции, проработки критериев или технического анализа, и вернуться к оценке в следующем цикле.
Это идеальный сценарий для Planning Poker. Scrum Master должен попросить этого разработчика объяснить, какие невидимые риски или технические сложности он видит, которые игнорирует остальная команда. Его задача — поделиться этими знаниями. После этого команда обсуждает риски и голосует снова. Нельзя просто усреднять или принуждать к оценке.
Карта “Бесконечность” (или “20+” / “100”) означает, что задача слишком большая и требует немедленной декомпозиции (разделения на части), прежде чем ее можно будет оценить. Карта “Чашка кофе” означает, что члену команды требуется перерыв или дополнительная информация, прежде чем продолжать оценку.
Нет. Product Owner (PO) и Scrum Master не должны голосовать, так как они не несут непосредственной ответственности за разработку и не будут выполнять работу. Участие PO в голосовании может создать “якорный эффект” и повлиять на независимое суждение команды. Их роль — предоставлять информацию и фасилитировать процесс.
В начале внедрения команда должна выбрать одну простую, хорошо понятную задачу (User Story) и присвоить ей эталонную оценку, например, 3 Story Points. Все последующие задачи будут оцениваться относительно этой эталонной. Это называется “базовой задачей” или “референсом”.