Прокачиваем оценку Scrum-команды

Использование Story Points (SP) в Scrum кажется чем-то естественном и само собой разумеющимся. Говорим Story Point - подразумеваем Scrum, говорим Scrum - имеем в виду Story Point. Правда же?
НО! Если мы откроем Scrum Guide и поищем там словосочетание "Story Point" то ... мы ничего не найдем! Сюрприз!

1. Что такое на самом деле Story Point?

2. Story Points и время

3. Story Point и реальность

4. Улучшаем оценку Scrum-команд

В Scrum Guide, в параграфе про Планирование Спринта написано:

"Developers обсуждают с Product Owner, какие элементы Product Backlog выбрать для включения в текущий Sprint. Scrum Team может попутно уточнять эти элементы, чтобы улучшить понимание и повысить уверенность. Выбор элементов, которые получится завершить за Sprint, может оказаться трудной задачей. Однако, чем больше Developers знают о своей прошлой производительности, своих возможностях на следующий Sprint и своем определении готовности, тем более уверенно они могут прогнозировать работу на следующий Sprint"

Вот и все 🤷

Никаких указаний на те или иные методики оценки, прогнозирования и т.д. И уж тем более нет конкретного указания на Story Points

Откуда же взялись эти Story Points?

В том виде, как мы их знаем сейчас, Story Points появились в книге Майка Кона "Agile Estimating Planning" которая вышла аж в 2005 году.

Изначальная идея заключалась в том, что Story Point это коллективная относительная оценка усилий, которые надо всей команде предпринять, чтобы поставить за спринт ценность. Задачи сравниваются между собой с точки зрения усилий всей команды.

Задача на 3 Story Points должна требовать в 3 раза больше усилий команды, чем задача на 1 Story Point.

Таким образом, вместо того, чтобы спорить о том, сколько часов может потребоваться лично каждому члену команды, команда сообща может быстро договориться, о соотношении задач между собой и проставить эквивалентное количество Story Points в качество оценки.

Так как это коллективный способ оценки, то очень глупо выглядят попытки некоторых команд, оценивать в Story Points работу каждого специалиста в ней, а потом складывать все эти оценки, надеясь получить точную оценку всей задачи. Это не будет работать, во-первых, потому, что при таком подходе каждый специалист будет использовать свои собственные относительные оценки, которые зависят от выполняемой роли.

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

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

Итак, Story Point это относительная оценка усилий команды. Как она соотносится с реальными сроками?

С одной стороны, исходя из Scrum Guide, оценка должна отвечать на вопрос "что мы успеем за Спринт?"

То есть минимальная точность оценки в Scrum равна длинне спринта.

А с другой стороны, Майк Кон в своей книге говорит, что 1 Story Point это некоторый диапазон возможных значений длительности. Например, простую задачу на 1SP делать не дольше 1 дня, но разные люди будут делать ее разное время в рамках этого 1 дня - некоторые 1 час, другие 3 часа или 6 часов.

То есть Story Point это некое вероятностное распределение реальной длительности задач.

В книге 2005 года это было проиллюстрировано так:

Обратите внимание, что края распределения 1 Story Point и 2 Story Point - пересекаются. То есть нет четкой границы между двумя соседними оценками в Story Points. И это естесственно, потому что мы не всегда знаем кто именно будет делать задачу, которую команда оценивает. Если ее будут делать новички - то для них задача на 2 Story Point займет гораздо больше времени, чем для опытных сотрудников.

С этой картинкой есть важный нюанс - на ней изображено так называемое нормальное распределение вероятности. Оно симметрично относительно центра распределения. А это значит, что можно взять значение по середине распределения и получить наиболее вероятное значение реальной длительности задачи

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

В 2022 году Майк Кон выпустил статью "Don’t Equate Story Points to Hours" в которой скорректировал картинку распределения реальной длительности для Story Points.

Вот как это выглядит в статье 2022 года:

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

Вершина может смещаться влево по разному для разных оценок в Story Points, и по разному для разных команд. Поэтому найти однозначное соответствие между Story Points и реальным сроком выполнения задач довольно трудно.

Когда мы даем оценки в Story Points, мы интутитивно ожидаем, что задача на 2 Story Points должна быть в 2 раза дольше, чем задача на 1 Story Points. И дальше в том же духе: 3SP в 3 раза долше чем 1SP, а 5SP в 5 раз дольше.

А как оно на самом деле? Что мы увидим, если соберем статистику о том, сколько на самом деле занимают задачи оцененные в 1 SP, 3 SP, 5 SP и так далее?

Такую статистику собрал активный участник Канбан-сообщества, Руководитель направления в банке Тинькофф Павел Ахметчанов, и вот что у него получилось:

Что мы видим?

Оценка в 2SP в реальности лишь в 1.5 раза дольше чем оценка в 1SP. Оценки в 3SP и 8SP сильно размазаны по времени, и может включать в себя задачи соседних оценок в SP.

То есть, каждая оценка в SP обладает своим уникальным распределением по времени.

Как тогда вообще можно пользоваться Story Points? Ведь мы рискуем попасть в ситуацию, как на картинке ниже :

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

Непонятно на что опираться при оценке? Как вообще можно быть уверенным хоть в какой-то оценке?

Здесь нам может помочь вероятностное прогнозирование.

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

Как это делать?

Пошаговая инструкция:

Шаг 1

Выгружаем из трекера задач в Excel данные по завершенным задачам за достаточно длинный исторический период - последний квартал или полгода.

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

Важно чтобы у нас по каждой задаче были даты начала работ - Start Date и дата окончания работ - End Date

Шаг 2

Для каждой задачи вычисляем разницу в днях между End Date и Start Date. Это будет время выполнения задачи - Lead Time

Шаг 3

По каждому типу задач построить частотный график Lead Time (Lead Time Distribution)

По вертикали - сколько раз мы наблюдали то или иное значение Lead Time. А по горизонтали - сами значения Lead Time, которые у нас в статистике есть.

Шаг 4

Используя формулы теории вероятности, вычисляем наиболее вероятное время в течении которого будут выполняться задачи разного типа.

Вот как это можно сделать:

А) Определяемся с вероятностью прогноза, которая нам интересна. Давайте выберем P = 85% - это обычная точность прогноза для большинства бизнес-задач

Б) Подсчитываем число M - общее количество задач конкретного типа, данные о которых отображены на графике

В) Определяем число N - количество задач, которое составляет 85% от общего количества задач: N = M * P

Г) Отсчитываем на графике слева-направо N задач, и то значение Lead Time на котором мы остановимся и будет временем выполнения, в течении которого задача будет сделана с вероятностью 85%

Пример:

На графике 1 выше, отображена частотная диаграмма по Доработкам.

Всего на графике представлено 66 задач (сумма значений всех столбиков по вертикали)

Для вероятности P = 85% значение N = 66 * 0,85 = 56,1

Отсчитываем слева 56 задач, и получаем значение Lead Time = 17 дней.

Это время, в течении которого будет выполнено 85% задач типа Доработка

Аналогичный расчет делается и для других типов задач

Шаг 5

Переводим получившиеся данные Lead Time в количество спринтов

Если спринт 2 недели (14 дней), то получим:

Любая Доработка - 85% вероятности сделать в течении 2-х спринтов

Любая Ошибка - 85% вероятности сделать в течении 1-го спринта

Любое Исследование - 85% вероятности сделать в течении 4-х спринтов

Шаг 6

Анализируем полученные данные для ближайшей Scrum-ретроспективе. Разбираемся, какие данные получились, и какие факторы способствовали самому длинному времени которое есть на графике, и что команда может сделать, чтобы ускорится.

Шаг 7

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

Если команда по какой-то задаче зайдет в тупик при оценке с помощью Story Points - она всегда может посмотреть на статистику, и быстро понять вероятную длительность задач в спринтах

Шаг 8(Опционально)

Возможно, вы захотите более подробно исследовать статистику Lead Time, типизируя задачи по следующим категориям:

А) По срочности задач (срочные, обычные, не важные)

Б) По сложности (простая, средняя, сложная)

В) По затронутым системам/платформам (core, интерфейс, модуль биллинга и т.д.)

Г) По количеству интеграций с внешними системами (нет интеграций, мало интеграций, много интеграций)

Разделив статистику по этим категориям, Scrum-команде будет еще проще определиться с оценкой и попадать в прогноз.

Вероятностное прогнозирование может уточнить оценку в Story Points и никак не противоречит Scrum.

Благодаря обилию трекеров-задач, доступных на рынке (JIRA, Kaiten, Asana и др) статистические данные собрать очень легко.

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

Если у вас остались вопросы, задайте их автору комментарием в канале "Данные в дейSTвии"

PS Перепечатка даннной статьи или ее части возможна только с согласия автора