Хочу поделиться своим подходом эффективного использования Стори Поинтов (Story Point/SP). Фундамент этого подхода заключается в том, что я запрещаю командам использовать SP для оценки всего, что есть в бэклоге. И сразу отвечу на вопрос “Чтобы что?” - Чтобы можно было отделить полезную работу, направленную на потребности пользователей, от “шелухи”.
И да, как шелуха помогает сохраняться зернам, так и презентации помогают сохранять команды, продукты и рабочие места. Но в хорошем продукте можно для работы над шелухой выделить отдельные команды, которые на этом будут сосредоточены, что несомненно будет позитивно влиять на сам продукт. Вопрос: как понять, когда пора формировать отдельные команды?
Несомненно, всё, что есть в бэклоге, важно!
Но тут важнее вопрос, кому и что действительно важно. Можем ли мы поставить на одни весы реализацию новой функциональности, закрытия техдолга, исправления бага, подготовки и проведения презентации, организации и участие во встречах. Это всё важные элементы выполняемой нами работы, оплачиваемой работодателем. И это всё необходимо оценивать.
Но если вдуматься, то не вся работа ценна для всех. Новая функциональность и исправленные баги важны, как правило, Владельцу Продукта и конечным пользователям. Закрытие техдолга, в первую очередь, интересует разработчиков и технических менеджеров. Имея незримое влияние на пользователей, презентации важны для совета директоров и прочих менеджеров, встречи важны для команды и для тех же HRов, хотя первые далеко не всегда это осознают. Конечно же, все активности и вся работа направлена на то, чтобы владельцы могли срубить побольше бабла пользователи были довольны и пользовались самым лучшим на свете продуктом. Или всё таки, чтобы владельцам срубить бабла? На самом деле, одно без другого в принципе невозможно, так как чем больше довольных пользователей, тем больше зарабатывают денег владельцы, после чего они вливают больше денег в развитие продукта и тем больше завоевывают сердца пользователей, и так по кругу.
Но всё же, если не будет пользователей, то, соответственно, не будет тех самых денег, которые зарабатывают владельцы, и тем самым не будет никакого вливания в развитие, да и развития не будет, так как не для кого это делать.
Таким образом, можно сделать вывод, что наиболее важный для нас персонаж - это пользователь того самого продукта. А вел я вас к этому заключению только для того, чтобы более ярко обозначить важность того, что делается для пользователей продукта.
Вы же не будете спорить с тем, что пользователям совершенно всё равно на то, какие и сколько презентаций было сделано, даже если бы без этих презентаций не было самого продукта. Как прошли те самые 100500 встреч и сотни тысяч исследований, которые на самом деле помогли стать продукту именно таким, каким они хотят видеть и какой он сейчас есть. Но то, что пользователю на это наплевать, не значит, что эта работа исчезнет, также не значит, что для такой работы не нужно использовать оценки и что она может существовать без дедлайнов.
Просто давайте Стори Поинтам отдадим то, что связано с Пользовательскими историями и Пользовательской ценностью. А всё остальное оставим в других системах координат.
Причем надо понимать, что это способ фокусировать в первую очередь команду и приближенных к ней на том, что команда сделала полезного для пользователей. Это также способ избавиться от демонстрации псевдо работы на цифрах/графиках и избавления от фраз “Ну я/мы/они же работал/и”.
Чтобы понять, что есть пользовательская ценность, я с командами разбираю всё, что они делают, и мы всегда приходим к тому, что для оценки в SP мы оставляем только: 1. Пользовательские Истории, 2. Технические Истории (техдолг) и 3. Баги. Все остальные задачи мы можем оценивать в часах или вовсе не оценивать, но остальные задачи тоже продолжают существовать. И мы просто не пытаемся запихнуть подготовку ко встрече в конструкцию Пользовательской Истории типа “Я как руководитель хочу посмотреть презентацию за квартал для того, чтобы оценить работу команд…” и т.п. Просто ВСЕ остальные задачи мы не оцениваем в SP.
Давайте разберем пример визуализации работы 2-х команд.
Дано:
Команда 1 оценивает в SP все, что есть в бэклоге.
Команда 2 оценивает в SP только задачи, связанные с пользовательской ценностью.
Левый вариант вроде +/- по-менеджерски понятнее, потому что раньше команды делали оценку в часах, при переходе на оценку в SP заменили одни циферки другими, и менеджеры спокойненько взирают по сути на то же самое, что и при оценке работы в часах. Им от этого спокойно, надежно и контролируемо, где нет ни одного неучтенного элемента. А если команда что-то не сделает, а это обязательно произойдет, будет возможность вздрючить для профилактики команду по конкретным цифрам, с процентами и т.п. Для руководства можно отчитаться, что всё под контролем и вы постоянно отслеживаете метрики по всем задачам, и, как следствие, показать результат на графиках в бесконечных презентациях.
Правый же вариант вызывает у таких менеджеров непреодолимое чувство тревоги, которое яркими пятнами неоцененных задач бросается в глаза своей неопределенностью.
И как бы ни казалось, что наличие оценок у элементов бэклога что-то может гарантировать, по факту, ни левый, ни правый варианты не дают 100%-й уверенности, что всё будет сделано в Спринте. Так что просто примем как факт, что цифры нам таких гарантий не дают. Единственное, что мы точно знаем, что наша команда точно потратит на задачи всё время, ограниченное Спринтом, что Спринт точно закончится и что время, проведенное командой в компании, придется полностью оплатить.
Теперь давайте вспомним одно часто забываемое правило работы в спринтах:
Члены команды самостоятельно решают порядок выполнения задач, историй, багов и других сущностей из бэклога спринта. При этом выбирая, что делать, постоянно ориентируются на цели спринта и на приоритизацию, согласованную с Владельцем Продукта во время планирования.
Чаще всего команда помнит только о том, что они сами решают порядок выполнения, при этом закрывая глаза на то, что они должны ориентироваться на поставленные на планировании цели, ну и конечно, что они коммитятся сделать всё, что взяли в бэклог ))
И частенько бывает так, что команда делает в спринте не то, что важно, а то, что удобнее и проще. Сразу обозначим, что я сейчас не пишу про хорошие команды, я пишу про только начинающие свой путь в Agile и пытающиеся “взломать” метрики или те, кого метриками замучали “эффективные менеджеры”.
В столбцах “SP” команд слева и справа обозначены зеленым завершенные задачи, а красным - незавершенные задачи, ориентированные на получение ценности для пользователей. Дополнительно во второй команде завершенные задачи без ценности для пользователя обозначены зелеными галками, а не сделанные никак не обозначены, потому что это “шелуха”, которой команды должны заниматься в перерывах между основными ценными задачами.
В итоге, давайте посмотрим на полученные результаты внимательнее. Дьявол как раз кроется в деталях, которые не всегда понимают начинающие эффективные менеджеры.
И левая, и правая команды выполнили согласно SP по 80% от запланированного, что является хорошим результатом.
И левая, и правая команда закрыла по одинаковому количеству элементов (задач): по 12 из 19. Что показывает так себе результат в 63% от плана.
В абсолютных значениях количество SP левой (41) команды выглядит намного выгоднее, чем у правой (17), независимо от того, что по первым перечисленным мной критериям они совершенно одинаковые.
У обеих команд также есть невыполненные элементы, которые они планировали сделать. Но из важных для пользователей элементов у левой не завершено 7 элементов, а у правой всего 3. И независимо от того, что у обеих одинаковое количество незавершенных элементов, действительно важных незавершенных элементов, которые повлияют на пользователя, у правой команды меньше. Именно оценки в SP в том числе помогают фокусироваться на важном. А без шелухи как-нибудь прожить можно.
Таким образом, мы видим наглядный пример, когда всего лишь из-за того, что в левой команде шелуха приравнена к пользовательской ценности, команда показывает хороший результат на графиках и презентациях, при этом с точки зрения пользователя эта команда принесла в 2 раза меньше полезной функциональности. Просто надо по-менеджерски немного умолчать про то, что именно и как считается, немного поиграть с полученными цифрами и спокойно показать результат “Вождям”.
От себя же, когда я вижу схожие результаты спринтов, я точно могу сразу сказать, что:
- в левой команде необходимо провести “колоноскопию” продуктового процесса, внимательно изучить хард скилл Владельца Продукта, вовлеченность и коммуникации команды разработки с ВП, в том числе с фокусом на давление со стороны ВП при планированиях, укомплектованность команды на предмет сбалансированной работы
- в правой команде явно видно, что им не хватает ресурсов на закрытие “шелуховых” задач, на что стоит обратить внимание, если вдруг проработка их будет иметь негативные последствия для дальнейшей работы над пользовательской ценностью.
И это мы с вами всего-то оооочень верхнеуровнево посмотрели на метрики и не взглянули даже на то, как команда достигает поставленную цель спринта, как и какие изменения происходят во время спринта, сколько техдолга регулярно открывается и закрывается, как себя чувствует команда и на сколько удовлетворенными ощущают себя пользователи продукта и владельцы бизнеса. Это всё “обстучим”, когда будем говорить про метрики.
Итак, способ, когда всё в бэклоге не оценивается в SP, помогает:
- Избавиться от оценивания того, что менее важно.
- Быстро увидеть, как команда приносит пользовательскую ценность.
- Мотивировать команду через визуализацию пользы для потребителей.
- Сосредоточить команду на главном.
- Верхнеуровнево опрозрачить проблемы, которые могут быть быстро решены, но которые могут оказаться фатальными, если их не замечать.
Ранее публиковал 2 статьи “Ваши Стори Поинты (Story Points/SP) не работают!” и “3 смертных греха при использовании SP”, и эту тему можно отнести к ещё одному смертному греху. Но учитывая, что это моё субъективное мнение, то и подход может быть не очень популярен. Надеюсь, что я смог объяснить пользу данного подхода. Если нет, можете делать так же, как и большинство, запретить я вам точно не могу.
P.S.
Если в вашей компании используется что-то из критикуемого мной, то это не обязательно должно гореть на костре святой инквизиции Agile, просто, возможно, вы используете какой-нибудь “<компанинейм>джайл” и/или работаете в компаниях, в названиях которых есть слова банк, нефть, газ, строй. В общем, не обращайте внимания, это не для вас, я просто вам завидую. Я точно это знаю, я в таких работал :)
P.P.S.
Сложность восприятия материала в этой статье 9 из 10.