В шапке
Метрики в Scrum

Метрики в Scrum

Любой команде нужно измерять прогресс, чтобы понимать, становится ли она лучше как команда или топчется на месте?

Чаще всего в своей практике при работе по Scrum или ScrumBut, я предлагаю команде измерять такую метрику как Velocity (можно перевести как «производительность» или иногда ее называют «скорость»). Как она измеряется?

Допустим, команда согласовала с Рroduct Owner восемь задач на спринт, и по каждой задаче были сделаны оценки в идеальных часах:

По завершении спринта команда на демо продемонстрировала результаты четырех из восьми задач:

Фактическое значение Velocity считается по плановым часам завершенных задач, то есть для этого спринта он равно:

Velocity  = 5+7+4 + 18= 34 часа.

Какую информацию получают участники команды при измерении Velocity?

Тренд по Velocity позволяет понять, сколько ценности в виде размера готового инкремента продукта команда поставляет в единицу времени.

Например, если мы видим вот такую картину, как на диаграмме ниже, мы можем предположить, что объем создаваемой ценности за спринт в среднем растет:

Пунктиром на диаграмме показана линия тренда, и она восходящая.

Допустим, эта метрика признается полезной и команда начинает ее измерять.

Каким должно быть плановое значение этой метрики, чтобы можно было сделать измерение и на его основании заключить, что производительность команды нормальная или даже отличная?

Для ответа на этот вопрос, на старте каждого спринта команда должна измерять еще одну метрику - Capacity спринта. Что это значит?

Допустим, в команде 5 человек, каждый из которых сообщает, какое  количество часов он планирует выделить на задачи следующего спринта:

Capacity данного спринта равно 82 часа. Это значит, что максимальное значение Velocity, которое может выдать команда за спринт не может превышать Capacity данного спринта (если, конечно, команда, не перепланировала спринт и не добавила по ходу в него задачу, которую успела выполнить).

Если команда спланирует спринт на 80 часов из доступных 82 часов, то плановое значение Velocity равно 80ти часам.

Вернемся к расчетам  фактического значения Velocity,  сделанным выше, где у нас получилось получилось Velocity  в 34 часа. Какой мы можем сделать вывод о сопособности команды фокусироваться на задачах спринта?

Что если рассчитать какую долю из запланированых на спринт часов, команда смогла использовать продктивно и превратить в готовой инкремент продукта?

Для этого фактическое значение Velocity  за спринт разделим на сумму плановых часов по запланированным в спринте задачам:

FF = Velocity /  ∑плановых часов по запланированным в спринт задачам *100  = 34/80 *100% = 43%

Метрика, которую мы рассчитали, называется Фокус фактор (FF) и ее измерение позволяет нам остлеживать динамику того, насколько команда адекватно планирует спринты и выполняет запланированные объемы работ, превращая их в ценность для клиента.

Если скрам мастер будет отслеживать тренд по FF, то на ретроспективе всегда можно будет обсудить, что мешает команде приблизиться к FF равному 100%?

Еще одна метрика, которую я измеряю для скрам-команды – удовлетворенность участников команды прошлым спринтом.

На ретро я прошу каждого участника команда оценить по 10-бальной шкале прошлый спринт и затем оценки усредняю. Измерение этой метрики и отслеживание тренда по ней позволяет делать выводы о том, как изменяются эмоции участников команды от спринта к спринту.

Это дает нам еще один повод на ретроспективе обсудить, что нам надо изменить, чтобы удовлетворенность выросла до 10 баллов?

Итак, это мой набор метрик для процесса разработки нового продукта, реализуемого по Scrum. А какие метрики используете вы и почему?

 

 

Комментарии (0)
Войти как