Как команды оценивают задачи в Scrum: разбираем planning poker

Когда команда садится оценивать задачи на спринт, часто происходит одно и то же: самый опытный или громкий участник называет цифру, остальные молча соглашаются. В итоге оценки нереалистичные, спринт трещит по швам, и все удивляются почему.

Planning poker решает именно эту проблему.

Что такое planning poker

Это техника групповой оценки задач, которую используют agile-команды. Каждый участник получает набор карточек с числами — обычно по шкале Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Числа отражают относительную сложность задачи, а не часы.

Процесс выглядит так: product owner зачитывает задачу, команда задаёт вопросы, потом каждый молча выбирает карточку. По команде все открывают одновременно. Если оценки близкие — берут среднее и идут дальше. Если разброс большой — те, кто поставил минимум и максимум, объясняют свою логику, и команда голосует снова.

Ключевой момент — одновременное открытие. Именно оно убирает эффект якоря, когда чужая оценка неосознанно тянет тебя за собой.

Почему это работает в Scrum

В Scrum спринты короткие, обычно две недели. Значит, ошибки в оценке бьют быстро и больно. Planning poker помогает не просто поставить цифру, а выявить непонимание задачи до того, как она ушла в работу.

Когда один разработчик ставит 2, а другой 13 — это не значит, что кто-то из них ошибся. Скорее всего, они по-разному понимают объём или требования. Разговор, который происходит после, часто важнее самой оценки.

Ещё один плюс — вовлечённость. Когда каждый голосует, никто не отсиживается. Даже джун думает над задачей и иногда задаёт вопрос, который не пришёл в голову старшим.

Онлайн-формат и инструменты

Распределённые команды не могут раздать физические карточки, поэтому используют онлайн-сервисы. Ведущий создаёт сессию, скидывает ссылку, участники заходят и голосуют с любого устройства. Всё то же самое, только без физического стола.

Для русскоязычных команд есть planning poker scrum — бесплатный инструмент без регистрации.

Частые ошибки

Торопиться с консенсусом. Если все быстро согласились — возможно, никто толком не думал над задачей. Расхождения в оценках это нормально и полезно.

Оценивать в часах, а не в story points. Часы создают ложную точность. Story points — это относительная сложность, и команда сама калибрует шкалу под себя со временем.

Пропускать обсуждение. Иногда хочется побыстрее закрыть покер и перейти к работе. Но именно обсуждение спорных оценок выявляет риски и неясности в задаче.

Когда planning poker не нужен

Мелкие очевидные задачи можно оценивать без голосования — просто договориться устно. Покер имеет смысл для задач, где есть неопределённость или команда раньше с таким не сталкивалась. Если все сразу понимают объём — формализм только тормозит.