Относительная оценка: всё ли сказано или ещё нет?

На написание данной статьи меня подтолкнули мои выпускники Школы Скрам-мастеров. На одном из занятий, я рассказывала им про относительную оценку и они попросили написать сказанное словами. В моей голове пронеслась лишь одна мысль: “Неужели ещё не всё написано по этой теме?”

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

Перед тем, как перейти к тому как и зачем команда использует относительные оценки, остановлюсь на ответе на вопрос “Почему последовательность Фибоначчи?”

Довольно часто меня спрашивают, почему в Agile используется адаптированная последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21, 40, 100. Всё дело в законе Вебера-Фехнера, суть которого заключается в том, что человек обычно замечает разницу между двумя объектами, если эта разница более 60%.

Вы можете легко это проверить сами, для этого сделайте такое упражнение: Представьте, что в правой руке грузик в 1 кг, а в левой в 2 кг. Ощущаете ли разницу? А теперь представьте, что в правой руке у вас грузик в 21 кг., а в левой 22 кг. Как у вас с ощущением разницы теперь? Разницу 21 кг. и 22 кг. сложно заметить, так как это всего 5%, в то время как 1 кг. и 2 кг. – это 100%

Именно закону Вебера-Фехнера подчинается последовательность Фибоначчи, поэтому она и используется как линейка для относительной оценки. Так как 0 не используется, команды начинают с 1. Максимальное значение, указывающее, что элемент бэклога можно сделать за спринт обычно обозначается 8, а иногда 13. Команды, с которыми я работала, чаще всего останавливаются на 8, а 13 используют как показатель, что требуется декомпозиция. 21 и 40 команда может использовать как показатель, что есть белые пятна в самом элементе бэклога и надо что-то прояснить (spike), а 100 - когда вообще ничего не понятно…

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

Перед тем, как ответить на вопрос “Зачем команде оценка?”, остановлюсь на том, что у оценки есть свои требования:

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

Представьте, что у вас есть элемент бэклога продукта (US/JS), для реализации которого вам потребуется фронт (FE), бэк (BE) и тестирование (QC). В команде у вас 2FE, 3BE и 2QC. Все эти участники команды потенциально могут заняться данным элементом бэклога, поэтому их задача слушать друг друга и понять сложность, объемность, новизну, риски реализации.

Послушав друг друга, они сбрасывают карточки из последовательности Фибоначчи – Покер планирование – которые показывают общую оценку реализации, а не только в своей части.

Допустим, у вас 5 участников и они сбросили такую последовательность: 3(FE-1), 5(FE-2), 5(BE-1), 8(BE-2), 5(QC-1), 5(QC-2).

Данные оценки, как лакмусовая бумажка, отражают насколько участники команды хорошо поняли друг друга. Задача Scrum-мастера/Agile-коуча (фасилитатора), задать вопросы тем, кто поставил минимальное значение, а также тем, кто поставил максимальное, что они в них вложили. В нашем примере, примечательно, что задачи разошлись и у одной специализации, что тоже необходимо прояснить. Бывает, когда кто-то вернулся из отпуска и не знает, что “выпилили” какой-то “костыль”, а бывает, что кто-то не занимался этим участком кода и не знает, что там есть “свои нюансы”, также бывает, что FE и BE не знают сколько сложностей может быть у тестировщиков, например, из-за того, что им надо поднимать стенды или ещё хуже, охранять их от других, так как кто-то может переписать данные…

Всё это проясняется в диалоге и участники команды выравниваются по пониманию сложности, объёмности, новизны и рисков в элементе бэклога продукта.

Какое ещё понимание даёт относительная оценка? Она помогает понять кому её взять. В ряде команд, с которыми я работала, мы выработали практику, что если элемент бэклога оценён в 8 и эта оценка продиктована, например, сложным BE, то этой задачей будет заниматься Senior, аналогично и для FE.

Данная практика хорошо пересекается с практикой в беге по пересечённой местности. Представьте, что перед вами на выбор несколько дистанций: 10 км - лимит по времени 2 часа, 35 км - 9 часов и 65 км - 14 часов. Если вы знаете свой уровень подготовки, а также, что вас ожидает на дистанции, то вы с легкостью можете понять, какую дистанцию брать:

Как и в беге объём задачи одинаков, лимит - спринт, а вот успеете вы или нет зависит от навыков, поэтому какие-то задачи делают Senior, какие-то Middle, а какие-то Junior, а когда Senior или Middle наставляет Junior, то он разрабатывает медленнее и это сказывается на общей скорости команды - поправка на инвестицию в развитие, так как без такой инвестиции со временем команде станет туго.

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

Допустим, вы приняли для себя решение о том, что будете оценивать в story points, с чего же начать?

Scrum-мастерам (агентам изменений) я всегда говорю наберитесь терпения, потому что вы знаете как это работает, а команде ещё перестраиваться и на это нужно время. Со временем команда понимает, что в целом в жизни она использует относительные оценки ежедневно, только не осознанно. Например, когда спрашивают: “как далеко находится магазин?” и вы отвечаете “примерно, 2 таких расстояния”. Если вы задумаетесь, то, думаю, найдёте массу примеров.

Первое, что необходимо сделать – это собрать фактуру, а точнее выполненные элементы бэклога . Собирается фактура обычно 3 спринта.

После этого команда, которая занималась delivery (реализацией), напоминаю, что мы не берём в расчёт работы связанные с подготовкой элемента бэклога продукта к стадии “готово к разработке” - эта часть часто называется discovery/анализ, и связана с подготовкой (“прожаркой”) элемента бэклога продукта до необходимого состояния, чтобы было понятно что будем реализовывать и будем ли.

Далее делается сетка с оценкой, на которой выкладываются выполненные элементы бэклога продукта. Я рекомендую найти элемент, который будет оценён на “3” и от него можно отталкивать в большую или меньшую сторону. Ничего страшного, если по какой-то причина команда не договориться по каким-то элементам бэклога, это откалибруется со временем. Также со временем у команды появятся свои паттерны, когда оценка будет проходить быстро, например, если задействованы все стеки - оценка 5 или 8, если только один стек и тестирование - 2 или 3.

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

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

Переоценка внутри спринта: итак, команда на планировании финализировалась с оценкой элементов бэклога продукта и объём (velocity) составил 32 story points.

Команда начинает работу и на 2-й день на дейлике один из участников команды говорит, что тот элемент, который оценили на 3 sp, на самом деле, по его части, сложнее и надо посоветоваться или делать этот объём или как-то иначе поступить. Все понимают, что объем надо делать и переоценивают элемент бэклога продукта, теперь он стал 8. О чём это говорит? А о том, что теперь объём (velocity) увеличился на +5 sp и в этот момент Владелец продукта должен понимать, что под угрозой может находиться US/JS, которая лежит в спринте как раз на эти 5 sp.

По этой причине я всегда рекомендую, чтобы ВП был на дейлике, несмотря на то, что Руководство по Scrum иного мнения.

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

Переоценка по окончанию спринта: завершается спринт и есть элементы, которые сделаны частично в этом спринте и будут перенесены в следующий спринт. Ряд Agile-коучей говорят, что надо переоценить и перенести только то, что осталось, однако, я придерживаюсь мнения, которого придерживается Майк Кон, что если вы не сделали элемент, то получили 0 в этом спринте, и все sp в том спринте, в котором сделали. Т.е., если вы оценили элемент бэклога на 8sp, и не сделали его в этом спринте, то заработали 0, а когда доделаете в следующем спринте, получите 8 sp. Вернусь к аналогии с бегом, если вы пробежали 5 км из 10 км, вы не заработаете медаль, медаль будет только после того, как преодолеете все 10 км, и кто сказал, что последние 5 км будут легче, чем предыдущие, плюс дистанция не была 5+5, а она 10 км и вы просто не уложились в лимит (спринт).

Почему я не сторонник переоценки? Опять же в будущем это осложнит команде сравнительную калибровку, так как историческая US будет 3 sp, в то время как реально она 8 sp, просто “переехала” в следующий спринт. А если смотреть на velocity, то при анализе коридора скорости команды всегда берётся средняя velocity и минимальная velocity, а максимальную никогда не трогаем, так как там как-раз таки и есть выброс на то, что переехало из предыдущего спринта.

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

Если вы правильно объясняете команде суть относительной оценки, с пониманием относитесь к тому, что команда не сразу принимает их и постепенно вводите, а с внешнем миром общаетесь временными диапазонами, то относительная оценка будет во благо, а не мучение.

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

Тренинг "Основы Agile и командной работы"

Школа Скрам-мастеров