Покер планирования - совместная оценка задач командой 💎 — OnAgile Consulting

Senior Agile Coach

Покер планирования - совместная оценка задач командой

Опубликовано

Planning poker (перевод с англ. — Покер планирования) — техника командной оценки задач в относительных единицах. Впервые описана в 2002 году Джеймсом Гренингом, одним из авторов Agile-манифеста. В дальнейшем популяризирована Майком Коном в книге «Agile Estimating and Planning». 

Достоинства техники:

  • Вовлекает всех участников в процесс оценки.
  • Позволяет сформировать у команды одинаковое понимание сути оцениваемой задачи. В результате оценки задачи с помощью Покера планирования команда понимает объем изменений и их сложность — за счет передачи знаний и опыта между участниками.
  • Позволяет команде за ограниченное время прийти к консенсусу в определении сложности задачи. Согласно исследованиям, такие оценки получаются более точными и менее оптимистичными.
  • Помогает минимизировать эффект якорения. Эффект якорения возникает, когда при оценке задач один из участников вслух произносит свою версию оценки сложности задачи, например: «Я думаю, что эта задача на 5 дней». В этот момент у других участников неосознанно возникает привязка к числу 5. Это число становится отправной точкой в их личном мыслительном процессе, задавая рамки. Например, если кто-то думал про оценку в 1-2 дня, после услышанного мнения в 5 дней он неосознанно захочет увеличить свою оценку. Особенно сильно этот эффект проявляется, когда первым говорит человек, являющийся формальным или неформальным лидером для команды.

Описание процесса планирования с использованием карт

Подготовка

Чтобы встреча командной оценки с использованием техники Покер планирования прошла продуктивно, мы советуем подготовить:

  • список задач на оценку, по которым владелец продукта может дать обзор, что и зачем необходимо сделать, и ответить на уточняющие вопросы команды;
  • колоды карт (дать ссылку на наши карты) для участников команды. Мы рекомендуем колоды, содержащие для оценки адаптированный ряд Фибонначи: 1, 2, 3, 5, 8, 13, 20, 40… Такой ряд хорошо отражает неопределенность, которая возрастает с ростом сложности оцениваемой задачи. Чем меньше задача, тем мы точнее можем понять ее трудоемкость. Мы отчетливо можем отличить сложность в 1 от 2 или от 3. С ростом сложности и неопределенности обеспечить такую точность становится трудно. И разница, скажем, между 13 и 20 не столь велика, риск ошибиться большой — как в большую, так и в меньшую сторону. Мы советуем командам декомпозировать задачи с оценкой 13 и более;
  • эталонную задачу, а лучше набор эталонных задач разного объема, например: 1, 3, 5. Эталонная задача — это задача, которая уже была выполнена командой, или по которой команда одинаково понимает, какие доработки были сделаны, и все согласны с указанной оценкой сложности. Эталонные задачи значительно упрощают и ускоряют процесс относительной оценки в команде.

Механика проведения Покер планирования

У каждого участника команды есть своя колода карт для оценки. Колоды содержат одинаковый ряд значений. Для того чтобы процесс относительной оценки проходил проще, желательно на встрече поместить в поле зрения команды набор эталонных задач (флипчарт, whiteboard и др.).

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

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

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

Как только все участники команды выложили свои карты, вскрываются значения. Участники с минимальной и максимальной оценкой рассказывают свои доводы, объясняя, почему данная задача сложнее или легче эталонной. В процесс обсуждения может вовлекаться вся команда. Фасилитатор следит, чтобы обсуждение не ушло в торги и нескончаемый спор. Цель обсуждения — обменяться опытом, понять, почему есть такой разброс оценок, и прояснить детали решения, которые помогут снизить разброс и прийти к консенсусу. Если в результате обсуждения выясняется, что команде не хватает информации, и участники не могут принять решение, оценка задачи откладывается и в бэклог добавляется задача (Spike) на проработку.

После обсуждения команда повторяет цикл голосования, пока не достигнет консенсуса в оценке сложности задачи.

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

Еще публикации по Agile в Agile, Scrum, Kanban–метод

Кейс
Телекоммуникации
Пилотный Agile в телекоме: перевыполнение плана на 45%
Командная работа как залог успеха и опыт внедрения Agile, готовый к масштабированию.
Публикация
Разработка ПО
Материалы для самостоятельного изучения Agile
Мы собрали для вас список самых важных книг на тему Agile и всего того, что пригодится на нелегком пути трансформации. Они могут вам самостоятельно изучить подход, а также закрепить и расширить полученные на тренингах знания.
Публикация
Разработка ПО
Agile как основа технологического бизнеса
Бизнес — это деятельность с целью получения прибыли. Технология — это знание, как делать что-либо. Соответственно, технологический бизнес — это знание того, как правильно действовать, чтобы получить прибыль.
Публикация
Разработка ПО
Что такое Непрерывная поставка (Continuous Delivery)?
При разработке программного обеспечения в стремительно меняющемся мире, часто возникает вопрос, как оставаться конкурентноспособным на рынке?

Мы помогаем организациям с 2004 года

Свяжитесь с нами

Дмитрий Лобасев

Executive Agile Coach & Founder

+7 495 221 87 39

dmitry@onagile.ru

Telegram канал об Agile и гибких организациях: https://t.me/agilethinking