Про опыт организации процесса оценки задач без scrum poker-а.

Как устроена оценка

В Scrum-практиках принято оценивать задачи.

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

Сейчас хочется обсудить чисто техническую сторону вопроса.

Часто под эту активность выделяется отдельная встреча, коллеги играют в т.н. scrum poker, и в целом весело проводят время.

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

0, 1, 1, 2, 3, 5, 8, 13, 21, ...

Или адаптированный вариант, именно для скрама:

1, 2, 3, 5, 8, 13, 20, 40, 100

Проблемы

Я вижу в таком подходе несколько недостатков:

• Числа подразумевают строгость (сколько вешать в граммах?), в то время, как “оценка” это вещь довольно примерная.

• Числовой ряд подразумевает большое количество вариантов - а это пространство для споров и конфликтов.

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

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

А вы были свидетелем обсуждения про то, что story points это не часы? 🕐

Я уже видел это несколько раз - в финансовых компаниях, в игростроительных, в сервисных. Same story everywhere.

Решение

У меня есть некоторый успешный опыт устройства этого процесса, которым хотелось бы поделиться.

Что понимаю под словом “успешный”:

• мне и коллегам стало комфортней
• из календаря ушла лишняя встреча
• производительность команды не ухудшилась

Очеловечиваем процесс

Первым делом стоит сделать шкалу поближе к людям.

Я вообще за людей и их эффективность 👨

Мы должны отказаться от числового ряда.

Оценку проще будет свести к двум показателям с малым числом градаций у каждого:

Объем - количество сущностей для обработки, время выполнения действий. Это про количество того, что придётся сделать.

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

В моем опыте эти градации назывались volume и complexity:

• Volume: small, medium, large
• Complexity: low, medium, high

Выбрать оценку по каждому из таких измерений уже сильно проще:

Градация мало-средне-много понятна и легко укладывается в сознание, она более человечная и понятная. Не требуется создания каких-то “карт эталонных задач”, по которым нужно было бы сверять, где у нас тут 1 поинт, где 3, а где 5.

У такой оценки меньше вариативность, а значит и меньше пространства для разногласий. Кажется близкой и реальной ситуация, когда два коллеги спорят, выбирая между 5 и 8 поинтами. В то же время, мне сложно представить (и я не встречал), чтобы кто-то спорил про “средне” или “много”.

Обычно такие оценки выставляются быстро и легко.

Примерами оценки таких задач могут быть:

Сохраняем измеримость

Допустим, мы сделали сам процесс оценки проще, но сколько теперь поинтов влезает в наш спринт?

Или как понять разницу в производительности двух коллег?

Это всё справедливые вопросы в ситуации, когда мы хотим принимать решения на основе фактов, а не ощущений.

Я справился с этим вопросом, составив матрицу соответствия.

Вообще, это почти универсальный рецепт, таблички всегда упрощают дело 📊

  volume        small   medium  large
complexity

  low            1        3       5
  medium         3        5       8
  high           5        8       13

Конкретно в этой табличке я считаю, что всё, что выше 13 поинтов - это вообще не задача, а странное нечто, которое забыли декомпозировать до более простого состояния.

В идеале, все задачи должны быть “на 1 поинт” 🐒

Втыкаем это всё в task tracker

Тут совсем просто, всё самое сложное мы уже продумали.

Далее просто ставим задачам лейблы volume: x и complexity: y.

Практика показала, что это настолько простой процесс, что его можно делать сразу при создании задачи, не унося на отдельный grooming/poker/planning.

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

volume:small + complexity:high = Points: 5

Дальше мы просто наслаждаемся тем, как коллеги по-человечески оценивают фронт работ, а условная Jira начинает сама рисовать какие-то красивые графики и чарты.

Готово.

Вы восхитительны!