Explore

Оценка SP

⁠

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

Зачем нужны оценки?

1️⃣ Первое (очевидное) - для прогнозирования. Если вы набрали сколько набралось и сделали сколько сделалось - то это никак не поможет в оценке будущего.

2️⃣ Второе (неочевидное) - это инструмент для обнаружения разных дисфункций. И конечно для того, чтобы поговорить. Все практики agile в первую очередь для того, чтобы поговорить. Вокруг процесса, работы, задач и так далее.

Кому нужны оценки?

1️⃣ Первое (очевидное) - продакту. Он думает, что понимает, сколько они с командой могут взять, сколько сделать, какая точность планирования. Как планировать будущие большие фичи. Как общаться с стейкхолдерами.

2️⃣ Второе (очевидное) - скрам-мастеру. С ними он может смотреть тренды, прогнозы. Становится больше данных для анализа и улучшения процесса. Даже без цифр, на основе самого обсуждения оценок, можно вытащить очень много идей для улучшения.

3️⃣ Третье (менее очевидное) - команде. Если инструмент оценок используется - команда будет и декомпозировать, и обсуждать, и выравниваться, и пробовать реалистично оценивать свои силы. Команда сможет тормозить “активного” продакта или наоборот вытягивать в Спринт больше (да, такое тоже бывает).

4️⃣ Четвертое (неочевидное) - другим продуктам/командам и компании в целом. Появляется возможность показать наружу скорость, прогресс, точность планирования. Решение смежных задач и зависимостей становится проще, особенно с работающими приоритетами.

Что использовать?

❓Story points, часы, майки, попугаи, изяны, идеальные человеко-дни. Какой из способов правильный? Любой, который работает в этой команде.

❓Может команда работать без оценок? Может, такие команды были в моей практике. И это либо команды, которые не оценивают и ничего не могут сказать про свой прогресс и скорость. Либо очень зрелые команды, которые настолько преисполнились в этой практике, настолько выровнены и круто декомпозируют, что могут считать в штуках, так как story у них +- одинаковые.

Почему story points?

Я работаю с любым форматом, но подход story points мне кажется более логичным.

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

Еще - у подхода в часах всегда есть “крышка” - условные 40 часов на человека в неделю минус встречи, обеды, перерывы, обсуждения и так далее. Это мало говорит о скорости. Фокус - не на получении результата, а на выполнении как можно большего количества работы.

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

Оценки в попугаях, изянах - относительные. К тому же - они выражены количественно (2 попугая, 5 попугая). Как и SP. Некоторым командам проще начать с них или с маек. Правильного/неправильного нет - главное, чтобы была польза.

Оценки в майках - относительные, как SP или попугаи. Но когда нам нужно понять емкость спринта - как сравнить например Спринт, в котором 3 XL, 1 L и 2 M, со Спринтом с 5 M? В каком спринте больше? Надо приводить к числам, например S -1 , L - 5, XL - 13. Иначе мы не посчитаем скорость, точность. Тогда проще сразу использовать SP. Поэтому дальше буду рассказывать про SP. Я не говорю, что только SP - рабочая тема. Используйте то, что удобно команде - лишь бы работало.

Важно, что SP - относительные оценки. Они оцениваются ОТНОСИТЕЛЬНО друг друга. Значит - для старта очень важно наличие эталонных задач. Также важно периодически сверяться с этими эталонами и с другими задачами. Пример сверки: Команда провела оценку Story, провели аж три раунда. Большинством голосов выбрали 8 SP.

Давайте сравним с другими 8 SP, которые уже были оценены? Похоже?

Если сравнить эту Story на 8 SP с вот этими на 5 SP и этими на 13 SP - то она больше/меньше?

Иногда на этих вопросах команда может еще раз переоценить. Команды это не любят, бесятся. “Мы же уже сказали, мы так одну Story сейчас будем час обсуждать!”. Да, вот так в начале это и работает. Да, и потом тоже периодически надо сверяться. Но чем больше сверяетесь - тем потом быстрее оцениваете. Чем больше таких ситуаций возникает - тем больше идей для улучшений есть.

👀 Наблюдения по процессу

Практики scrum/agile/прочего - это комплекс. Например, Рождество или Новый Год - это комплекс. Если вы просто бросите носок у печки - ощущения Рождества не будет. Если вас никто не поздравит с днем рождения, не будет подарков и других атрибутов - тоже будет грустненько. А вот если елка в доме и наряжена, играет Frank Sinatra (у меня это он), украшения - тогда ощущение есть. С практиками так же. Если вы берете кусок - то вся практика может не взлететь. Конечно, не всегда есть возможность/необходимость сразу все подготовить, готовиться несколько месяцев, чтобы что-то попробовать. Но если пробуете и не получается - проверьте еще раз, а все ли вы делаете. Может у вас просто брошен носок у печки. Дальше расскажу свои наблюдения за время работы с командами.

💭 Нужно быть готовым больше разговаривать.

Любые практики в scrum и так далее - в первую очередь про поговорить, обсудить, выровняться, шарить экспертизу и понимание. Если не говорить - оценки работать не будут. Поэтому важно при оценке использовать слепой метод - когда выложили оценки, и если расхождения - говорим, почему такую оценку поставил и опять молча переоцениваем. И важно именно обсуждать, а не “Ну Толя сказал, тут 3 SP - значит 3”.

💭 Story points - это оценки Story.

Если у вас не Story или не около того - нормально может не работать.

❓Можно ли в SP оценивать таски и потом складывать в оценки? Можно конечно, но работать не будет.

❓Можно оценивать только фронтами story на фронт? Можно, но это не story и оценки работать не будут. И пространства для обсуждения там будет существенно меньше. Для того, чтобы оценки были полезны - может потребоваться пересобрать бэклог (не все PO это любят). Может потребоваться перестроить процесc PBR (у вас же он есть?), декомпозицию.

💭 Эталоны нельзя сделать 1 раз.

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

После этого попросил команду подготовить истории для эталонов:

🧩 Завершенные истории

🧩 Разного размера

🧩 Те, которые вы очень хорошо запомнили (было много проблем или наоборот решили очень просто. Запоминающиеся обсуждения и так далее). Чем ярче - тем проще потом.

Далее - мы сначала распределили их слева направо (потренировались в относительности). После этого - начали выборочно оценивать и формировать границы - оценили что-то на 13, потом что-то на 5. У же есть две границы - остальное сверяем. Получилось как на скриншоте ниже (еще не все эталоны оценены).

Теперь, когда мы оцениваем новые, еще не готовые story - сравниваем их с эталонами. В первое время осознанно тратим на это больше времени - зато потом будет проще.

💭 “Я джун/новый сотрудник - как я смогу оценивать?”

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

💭 “Я дизайнер - как я смогу оценивать? я в вашем коде ничего не понимаю”.

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

💭 Definition of Done (a.k.a. DoD). При оценке в SP мы оцениваем какой-то объект работы - Story. В этот объект работы входят задачи. Story считается завершенной (а SP - “заработанными”, выполненными), когда она достигла понимания “Готово”. “Готово” - это DoD (definition of done) и Acceptance Criteria (критерии приемки). ❓Можно ли оценивать в SP, если в команде нет понимания DoD и не используются ни в каком виде критерии приемки? Можно, но оценки будут скакать. Если в течение Cпринтов вы видите постоянную потребность в переоценке, “а мы то думали, там другое надо сделать” - стоит обратить внимание на DoD и AC.

💭 Definition of Ready (a.k.a. DoR). Чтобы оценивать этот объект работы, нужно понимать, о чем идет речь. Для этого можно использовать DoR. DoR - это фильтр на вход. Если пункты из DoR есть - нам достаточно информации, чтобы оценивать. Чем больше пунктов - тем проще оценить и тем дольше их выполнять. Чем меньше пунктов - тем сложнее оценить, но оценить и начать можно раньше. У зрелых команд может быть очень короткий список в DoR или его вообще может не быть. У малоопытных команд тоже может не быть DoR, но между ними будет большая разница - первые уже много чего переделали, хорошо разобрались в продукте и всем, что под капотом. И могут себе это позволить.

💭 Проводи аналитику, сам и с командой. Периодически я выгружаю оценки и смотрю их lead time. Это может и не канонично, но что поделать.

Запоминайте и разбирайте то, из-за чего пробуксовывают оценки.

Из-за чего происходит много этапов голосования? И из-за чего возникает сильный разброс в оценках? О чем долго не могли договориться эти двое (или трое)?

Можно ли выделить группу историй, по которым больше всего проблем с оценками и их точностью? (интеграции например).

Как проверить, что оценки работают?

🥷🏼 В процессе оценок нет дисфункций (перечисленных выше или других, обнаруженных тобой. Знаешь другие - поделись с каналом🥺)

🥷🏼 Эталоны SP обновляются и актуальны.

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

🥷🏼 Косвенно - переносов из Спринта в Спринт меньше.

Чаще всего в самой story будет отображено, в каких Спринтах она была задействована. Это всегда можно выдернуть и руками без сложных автоматизаций.

🥷🏼 Отчет “Диаграмма производительности” выглядит +- ровно.

****Если скачки редкие - стоит посмотреть, что такого было в Спринте. Если они постоянны, тогда оценки точно стоит проверить. Этот график может выглядеть хуже просто потому, что Спринт в Jira стартуют раньше, чем положат и оценят в Спринт story🫠).

🥷🏼 Если выгрузить все Story и сгруппировать по оценкам (например, все 8), то можно:

🧩 посмотреть среднее/медианное значение lead time. Если по какой-то группе оценок среднее/медиана больше или равно длине спринта - нужно работать над декомпозицией и не брать в спринт большие.

🧩 Если волатильность (разброс) слишком большие - значит нужно обратить внимание на эталоны и свериться с ними. Например, если в группе 8 SP есть story, которые закрываются за 3 дня и те, которые закрываются за 83 дня - ваши оценки не работают.

Я просто выгружаю из Jira в excel и группирую, как удобно. В эталоны кстати тоже можно добавлять факт по lead time.

Как еще можно использовать?

Считать стоимость story. Да-да, это тоже не канонично, не точно. Но если нужно, а других подходящих вариантов нет - можно и попробовать.

Например, вы работаете спринтами 2 недели. Ваша прогнозируемость - понятна. Точность планирования +- стабильна.

Команда, например, делает за спринт 30 SP. Стоимость команды за спринт, например, 3 млн. Сколько будут стоить 5 SP? 500 тысяч рублей. Очень грубая и неточная оценка. Что она даст?

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

🧩 “Что мне с этим всем делать?”

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

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

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.