Покер планирования - совместная оценка задач командой 💎 — 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–метод

Публикация
Мода
Секрет головокружительного успеха ZARA
В 1975 году Амансио Ортега Гаона открыл первый магазин одежды ZARA. В мае 2016 года Forbes оценил стоимость бренда ZARA в 10.7 миллиарда долларов. Каким образом ZARA удалось занять лидирующие позиции в модной индустрии оставив конкурентов далеко позади?
Публикация
Agile, Scrum, Kanban–метод
Выбор пилотной команды для внедрения Agile
«С какой команды лучше начать пилотное внедрение Agile» — часто спрашивают нас клиенты, особенно в крупных компаниях.
Публикация
Agile, Scrum, Kanban–метод
Agile + Lean: комплексный подход к изменениям в компании
Agile и Scrum сейчас очень популярны. К нам обращается огромное количество компаний с просьбой внедрить Agile-практики и обучить сотни сотрудников. Но всегда ли требуется, а главное, подойдет именно Agile / Scrum?
Публикация
Agile, Scrum, Kanban–метод
Product owner и скрам-мастер: почему важно разделять эти роли
При внедрении Scrum появляются две новые роли: владелец продукта и скрам-мастер. И часто бывает, что на них решают назначить одного человека — обычно это менеджер проекта или тимлид. Но это не лучшее решение.

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

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

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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