Опасно ли рассчитывать стоимость Story Point?

Перевод оригинальный статьи Mike Cohn с разрешения Mike Cohn.
Поработав какое-то время со Story point (относительная оценка, далее - SP), команды начинают понимать, что могут рассчитать стоимость SP для команды. А владелец продукта команды - что может использовать эту величину для принятия решений. Предположим, например, что стоимость SP команды - $2000. Владелец продукта может оценить, что элемент бэклога продукта на 10 SP будет стоить примерно $20 000 и решить, стоит ли этот элемент инвестиций.

Причем зачастую, когда команда поняла, что такие вычисления возможны, она приходит ко мне с вопросом, а не опасно ли это?

Прежде чем решить, опасно ли рассчитывать стоимость SP команды, давайте посмотрим, как это можно рассчитывать и использовать.
Расчет стоимости SP
Чтобы рассчитать, сколько стоит доставка SP, начните с выбора подходящего периода для расчета. Я советую использовать как минимум три спринта. Вообще-то, я предпочитаю использовать три месяца, а это, скорее всего, больше спринтов (в зависимости от длины спринта).

Подсчитайте суммарное количество поставленных SP за период. Для этого просто сложите velocity (производительность в SP за спринт) каждого спринта. Используем данные следующей диаграммы производительности. В течение семи показанных спринтов (14 недель), команда поставила 167 SP.
Далее определите, сколько команде заплатили за этот период. Отдел кадров вряд ли поделится с вами информацией об индивидуальной зарплате, но, вероятно, они могут предоставить общую сумму. Всё, что вам нужно - это знать сколько заплатили команде за период.

Вам следует подумать, кого вы хотите включить в этот расчет. Может быть, ваша команда иногда консультировалась с архитектором. Или она работает с DevOps-инженером, который официально не входит в команду, но помогает несколько раз в неделю. Определите для себя, включаете ли вы часть зарплаты этих ребят. Обычно, частично привлекаемые специалисты не оказывают материального влияния на решения, основанные на стоимости команды на SP.

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

Я рекомендую не учитывать полную стоимость труда или частично привлекаемых участников команды, так как это обычно не ведет к принятию других решений.
Пример
Предположим, у нас есть команда из восьми человек, которым за 14 рассматриваемых недель заплатили $160 000.

Из диаграммы velocity выше мы определили, что команда поставила 167 SP. Чтобы определить стоимость SP, разделите общую стоимость ($160 000) на количество SP (167) и получите $958 на SP.
Использование стоимости SP
Бывают разные ситуации, в которых полезно использование стоимости SP. Прежде всего, стоимость SP может быть чрезвычайно полезной владельцу продукта, которому надо решить, стоит ли фича того, чтобы её разрабатывать.
Приоритизация
Представьте, что вы владелец продукта команды, которая оценила фичу в 40 SP. Зная, что стоимость SP составляет $958, вы можете задать себе вопрос, стоит ли фича $38 320 ($956 x 40).

Вообще-то, я надеюсь, что вы округлили и спрашиваете, стоит ли фича $40 000.

А ещё лучше для владельца продукта понимать, что 40 SP - это оценка команды. Решение относительно разработки новой фичи должно учитывать прочие риски. Я бы рекомендовал владельцу продукта добавлять хотя бы 50% и рассматривать целесообразность разработки фичи за такую стоимость.

Сегодня я купил старый номер журнала Rolling Stone, чтобы повесить на стене в офисе в рамке. Он стоил $200. Так как поручиться за качество 45-летнего журнала могли только фотография и слово продавца на eBay, я спросил себя, готов ли я заплатить $200, если бы журнал не был так безупречен, как я надеялся.

Когда владелец продукта принимает решение о приоритете, с ним происходит то же самое. Я бы не хотел, чтобы владелец продукта просил команду разработать фичу, оцененную в 40 SP, если он не готов её разрабатывать при оценке 41 SP.
Оценка стоимости разработки
Связанное с этим использование стоимости SP - это оценка стоимости разработки продукта, проекта, набора фич.

Часто она применяется в заказной разработке. Представьте, что компания приходит за заказной разработкой, чтобы создать новый продукт. Команда оценивает его в 200 SP. Зная, что в команде SP стоит $958, команда может выполнить расчет (200 SP x $958) и определить, что разработать продукт будет стоить чуть меньше $200 000.

Обратите внимание, что это цена не для выставления клиенту. Это была чистая цена труда, без учета буфера на неопределенность, управление проектом, работу c клиентами, прибыль. Но $200 000 можно использовать как точку отсчета, чтобы учесть, что дополнительно нужно заложить в стоимость.
Опасности использования стоимости SP
Обратите внимание, что для этих способов использования стоимости SP команды использовалась агрегированная ценность. Это была стоимость команды, а не одного человека, выполнявшего работу. И это была средняя стоимость большого количества SP (40 и 200 в двух примерах).
Опасность 1. Скудные данные для определения стоимости SP
Выше были приведены корректные способы использования данных о стоимости SP. Все может пойти не так, если вычислять стоимость SP на скудных данных. Я часто встречаю ошибку, при которой стоимость SP вычисляют на уровне людей, для индивидуальной velocity каждого участника. Это очень плохая идея.

Вы не можете рассчитать индивидуальную velocity, потому что у команды не должно быть элементов бэклога, которые может поставить один человек. Типичный элемент бэклога требует участия программиста, тестировщика, DBA, аналитика, UI-дизайнера и т.д. При таком количестве вовлеченных компетенций выделить SP на каждую роль невозможно. Поэтому velocity вычисляется только на уровне команды.

Скудность данных может возникать при рассмотрении слишком маленьких элементов бэклога. Представьте элемент бэклога на 2 SP и предположите, для простоты, что эти SP равномерно распределены между кодированием и тестированием.

У команды есть только один тестировщик, но два программиста, каждый из которых может взять задачу с равной вероятностью. Зарплата одного программиста вдвое больше, чем у другого, но пишет код он в три раза быстрее. На слишком маленьких элементах бэклога, стоимость SP может зависеть от того, какой участник команды выполняет работу.

Но, если эта же команда использует стоимость SP для принятия решений относительно работы на 100 SP - уже не так важно, кто из разработчиков будет делать какую работу. На больших объемах работы значения усредняются.

Следует быть осторожным, используя стоимость SP на малых масштабах.
Опасность 2. Сравнение команд по стоимости SP
Самое опасное в расчете стоимости SP - это то, что кто-то вне команды будет использовать ее как основу для сравнения с другими agile-командами. Это недопустимо, потому что velocity двух команд нельзя сравнивать, если только команды не предприняли значительные усилия для установления и поддержания общей базовой оценки SP. Причем, даже в этом случае иметь общую базовую оценку может быть не такой хорошей идеей.

Желание сравнивать команды на основании стоимости SP следует из ошибочного предположения, что velocity можно использовать как метрику продуктивности. А это не так. Вполне возможно, что команда с более низкой velocity более продуктивна, чем команда со значительно большей velocity.
Стоимость SP может помогать принимать решения
Я верю, что понимание стоимости SP может помочь людям делать выбор. Эту метрику легко посчитать и просто использовать в разных ситуациях. Округленных чисел и грубых оценок достаточно, чтобы помочь владельцу продукта решить, стоит ли фича усилий по ее разработке.

Главная опасность - использование для сравнения команд - не нова для большинства скрам мастеров или коучей. Стейкхолдеры часто пытаются сравнивать команды, но они будут сравнивать команды и на основании velocity, поэтому знание стоимости SP для каждой команды не ухудшает ситуации.
А вы что думаете?
Каков ваш опыт по расчету стоимости SP команды? Было ли это полезным? Применяли ли вы ее способом, отличным от того, что я описал? С какими проблемами (если они были) вы столкнулись? Пожалуйста, поделитесь своими мыслями в нашем telegram канале AgilePub или оставьте комментарий к оригинальной статье.