Овечном:обоценках

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

Должны ли мы производить оценки элементов бэклога только на grooming-ах? После или до них?

По-моему мы немного спешим с постановкой вопроса, ведь до того как ответить на этот вопрос мы, сначала, должны ответить себе на следующие вопросы: “Для чего мы делаем оценки? В чем ценность оценок?”

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

1. Число, полученное в результате оценки, должно улучшить возможность команды взять на себя обязательства во время планирования спринта сделать тот или иной объем работы во время самого спринта. Желательно, чтобы это число, было результатом обсуждений всеми членами команды вопроса о возможных способах решения представленной перед ними проблемы (сформулированной в виде пользовательской истории), и, общепринятого решения о том, какой же из возможных путей решения они выбирают.
2. Число, полученное в результате проведения оценки, также является важным для Product Owner-а. И должно помочь с предсказаниями о прогнозируемом содержании следующего релиза.

Важно помнить, что все эти оценки являются лишь догадками, нашими наилучшими прикидками, и, скорее всего, будут не верны. Число оценки поможет Product Owner-у и команде изменить очередность элементов бэклога таким образом, чтобы достичь наилучшей возможной комбинации:

• эффективности
• ценности
• качества
• снижения рисков

Последнее означает, что вся скрам команда (влючая PO), совместно может решить, что они хотят включить в текущий спринт несколько более мелких истории меньшей важности, чем более важную историю, которая рискует быть не выполненной в течении спринта, поскольку она слишком большая.
Оба пункта а) и b) становятся ненужными с того момента, когда команда достигнет способности нормализации элементов бэклога, таким образом, что они смогут брать на себя обязательства о выполнении определенного количества нормализованных элементов бэклога (обычно 6-10).

Другими словами, если команда научится измельчать эпики (epics) на истории примерно одного размера, им не нужно будет оценивать.
Время, затраченное ранее на произведение оценок, сможет отныне тратиться на обсуждение и нормализацию историй.

В этой связи хочется упомянуть Критерии готовности элементов бэклога (Definition of ready), которые являются инструментом, помогающим нормализовать входящий поток (историй), а также, Критерии готовности (Definition of done), которые являются инструментом, помогающим нормализовать исходящий поток. Кстати, у кого есть лучшие русские термины для этих двух понятий добро пожаловать в комментарии :).

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

В частности, вы получите больше возможностей спросить команду помогут ли им, только что упомянутые аргументы, для получения более точных оценок или нет, что (при ответе “да”) будет означать, что они достигнут большего понимания элементов бэклога и будут чувствовать себя более уверенными для того, чтобы взять на себя обязательства по выполнению работы. Так что покер может помочь команде сохранить фокус, достичь общего понимания историй, равно как и поможет с самим процессом фасилитации. В качестве бонуса, вы еще получите числа для бэклога :).

Давайте также обсудим ситуацию заякоривания (которая может означать наличие усталости в команде), когда люди просто голосуют 3 не имея никакого понимания. В этом случае люди не хотят оценивать, они не видят в этом никакой пользы и поэтому просто следуют за лидером и сразу соглашаются с его аргументами не высказывая своей точки зрения (поскольку это позволяет мучениям закончиться быстрее).

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

Решением является уход из ловушки “получение оценок” и фокусировка на построении и генерировании ценных знаний. Альтернативно, если вы видите, что команда продолжает голосовать в быстром темпе и без обсуждений, можно предложить команде совсем уйти от голосования картами, и переключится на простое поочередное обсуждение историй (само собой с ограничением по времени).

Многие злоупотребляют покером планирования, и, поэтому, люди перестают думать. В результате чего, никто уже ничего не оценивает, а люди просто делают Product Owner-а счастливым играя в его “глупую” игру. Команда перестает видеть связь между “это 3 стори поинта” и последующим принятием на себя обязательств сделать это.
Явный признак подобной ситуации – неустойчивые финальные обязательства по окончанию планирования спринта. Один спринт команда берет на себя обязательства сделать X стори поинтов, а на следующий спринт Х*2. Они как бы не верят своим собственным оценкам, работают “на автомате” когда сложность работ низкая, и, спотыкаются, когда касаются более серьезных вещей.

Все мы помним о Законе Паркинсона: “Работа заполняет, отпущенное на нее время”, и любая мелочь может занять (читай, мы ее растянем) 3 стори поинта :). Поэтому, давайте пользоваться покером, для инициации разговоров, а не для получения цифр.

А как работаете вы в своей команде? Делаете или не делаете оценки? С покером или без? Что случается, когда оценки историй меняются внутри спринта?