Уже много раз мне приходилось объяснять командам, как правильно пользоваться «Попугаями». Теми самыми Story Points, которые применяются для оценки Бэклога (backlog) и высокоуровневого планирования. Несмотря на то, что практика Planning Poker всё чаще входит в жизнь команд, этого оказывается недостаточно, чтобы команды научились делать оценки легко и быстро. Иногда, если людям дать только колоду карт со стандартными инструкциями в коробочке, то этого оказывается мало и со временем команда перестаёт использовать этот механизм оценки.
Вот как можно быстро объяснить суть идеи вашей команде…
Во-первых, напомните всем, что оценка в «Пунктах» (“попугаях”, story points) – это сравнительная оценка, которая показывает «размер» требований относительно друг друга. Т.е. важны относительные значения и не может быть эталона. «Пункты» не имеют физических единиц измерения.
Во-вторых, проведите калибровку, т.е. приведите всю команду к единому пониманию размеров, чтобы представление о «пунктах» были у всех одинаковы.
Для этого вам нужно взять те запросы, которые ваша команда уже делала в течение последних 3-4 недель. Распечатайте на отдельные карточки или выпишите на отдельные листики код (ID) и краткое название, чтобы все могли определить, о чем идёт речь. После этого разложите карточки в ряд, от самых лёгких до самых сложных. Сравнивайте запросы между собой и оценивайте их размер.
Представьте себе, что Размер = Работа x Сложность x Неуверенность.
Когда у вас получится линия, в которой запросы отсортированы по размеру, вы можете взять карты Planning Poker или просто шкалу Фибоначчи и положить рядом с требованиями. Теперь нужно сгруппировать требования вокруг чисел.
Ничего страшного, что некоторые требования приходится класть «в одну корзину». Напоминаю, мы не измеряем размер в метрах, килограммах или других единицах. «Пункты» не имеют размерности – важно относительное сравнение запросов между собой и их распределение по шкале.
Ещё пару советов:
- Не используйте числа больше 13 или 20. Если вы оцениваете работу, которую вы уже однажды сделали в течение итерации, то на шкале должно оставаться место для больших запросов, которые больше итерации
- Не верьте в то, что бывает работа, требующая 0 (ноль) усилий :-). Даже самый маленький запрос требует какого-то времени. Используйте карту со значением ½.
Итак, у вас есть некая шкала, на которой вы расположили требования/запросы, которые вы уже делали. Теперь каждый раз, когда нужно оценить новое требование, члены команды могут мысленно сравнить его с другими, которые были оценены раньше. Это и есть оценка сравнением, и теперь вы можете спокойно играть в покер :-).
P.S.
Меня часто спрашивают, что делать командам, которые раньше не работали вместе или делают новый проект и у них нет возможности взять сделанные требования за 3-4 недели? Возьмите те требования, которые нужно оценить и тоже выложите их в линию согласно вашему пониманию сложности. Даже если вы потом выясните, что ошиблись, это лучше, чем сейчас терять время в безнадёжных попытках дать более точную оценку, которую вы все равно не можете дать.
P.P.S.
Еще статьи по теме оценок:
Еще один способ быстрой оценки Бэклога в Пунктах или как оценивать играючи
Как правильно использовать скорость команды и оценки в пунктах
what is related to story points i tried to explain it in a bit different way. I made an analogy to simple physical formula: V (speed) = S (distance) / T (time)
V is team’s velocity and it can change over time. We can go faster or slower which depends on situation – someone i sick, we face a lot of impediments and etc. Team’s goal is to achieve constant/predictable speed.
T is our fixed sprint time box (2 weeks)
S is size of our features that we want to estimate. It’s a common thing to measure destination in meters (Europe). So team’s goal was to identify “our” meters, to make it easier we took some already implemented tasks as standard for our measures.
You can read more here:
http://www.agilemindstorm.com/2010/10/largest-impediments-you-have.html
Хорошая статья. Дам дополнительно пару советов:
– Иногда действительно попадаются задачи, которые хочется оценить в 0. Оценивайте их смело в 0, иначе у вас потом возникнут затруднения в оценке относительно этих задач. Но очень важно помнить, что сумма 0 не есть 0! Поэтому введите курс конвертации, который вы будете применять при определении объема работ на итерацию (к примеру 4 * 0 = 1). Курс зависит от команды.
– Я бы советовал стараться не использовать карточки выше 5-8 вообще на уровне планирования итерации. Старайтесь разбить требования на более мелкие, это добавляет предсказуемости и помогает лучше отслеживать прогресс.
– Время от времени анализируйте не стал ли ваш эталон слишком мелким. Такое случается когда команда сильно выросла и набралась технического опыта. Явным показателем будет являться наличие высоких оценок практически на любое требование. В этом случае стоит обсудить введение нового эталона и “переоценку ценностей”.
– Во время оценки требований в “попугаях” постарайтесь вообще не думать о времени. Считайте что вы оцениваете требования не своего проекта. 😉 Тогда вы получите наиболее объективную относительную оценку сложности.
В целом, главное, чтобы процесс оценки был как можно более интуитивно понятным (http://xpinjection.com/2010/10/05/simple-and-intuitive-processes/). Тогда он не вызовет у вас никаких сложностей.