Сеть оценок для планирования в Scrum

в 5:25, , рубрики: agile, scrum, story point, оценки, скрам, управление проектами

Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?

Предлагаемое решение

Решение, которое я называю “оценочной сеткой” — визуальная таблица, по одной строке для каждого размера истории, которым вы пользуетесь. Если вы пользуетесь рядом Фибоначчи для оценок, у вас будут строки для “0.5”, “1”, “2”, “3”, “5” и “8”. Затем для каждого размера (в каждую строку) вы размещаете несколько карточек с историями, примерами в этом размере. Вот иллюстрация как это должно выглядеть:

Сеть оценок для планирования в Scrum
Такая сетка на виду у вашей команды делает процесс оценок значительно проще, потому что у вас есть несколько примеров историй в каждом размере, и вы можете сравнить вашу новую историю с этими примерами.
Как заполнить эту сетку в самом начале..? Общее правило такое: добавляйте только «типичные истории», если есть шанс, что вы будете делать что-то подобное в будущем.
Желательно помещать истории в сетку после того, как мы завершаем работу с ними, что бы у нас был реальный опыт.
Инструмент «Сетка оценок» нацелен на помощь с будущими оценками. Поэтому, если какая-то конкретная история была уникальной, и вряд ли вы будете делать что-то подобное в будущем – для такой истории нет места в сетке.

Ещё пара советов как построить сеть

Ещё один трюк, снимающий сложности, которые могут возникнуть у многих членов команды: важно помнить, что значит конкретное значение оценки. Например, «5» — это сколько? Давайте вспомним, как мы проводим оценки. Если команда верит, что размер истории больше «3» и меньше «5» – он становится «5». Так что «5» означает все истории в интервале от 3 до 5. Если вы это помните, становится намного проще поместить две достаточно разные по размеру истории (например, одна чуть больше, чем 3 и другая чуть меньше, чем 5) в один ряд, как одинаковые. Я даже показываю эти интервалы рядом с размером в первой колонке (как вы можете видеть на картинке) чтобы визуально напомнить об этом. И вы пересматриваете и улучшаете эту сеть со временем. Во время ретроспективы каждую итерацию, или раз в несколько итераций, вы проходите по сетке, чтобы проверить все ли присутствующие там истории всё ещё актуальны, и, может быть, стоит добавить новые истории, с которыми вы работали.
Лучше всего если у вас будет 2-5 карточек примеров в каждом размере. Вам нужен какой-то минимум как базис для оценок, и у вас не должно быть слишком много примеров, потому что это только затруднит и замедлит сравнение.
Пара примеров как это может выглядеть в реальной жизни:

Сеть оценок для планирования в Scrum Сеть оценок для планирования в Scrum

Нет смысла помещать в вашу сетку все возможные размеры историй (как 20, 40 или 100). Нужно сфокусироваться только на размерах, которые актуальны для историй достаточно маленьких, что бы зайти в итерацию. Это зависит от вашего выбора размера. Моя рекомендация – всё до 8.
Этот инструмент очень просто внедрить и использовать. Из моего опыта, у него очень низкий уровень сопротивления со стороны команд, то есть его хорошо принимают. Это пример простого процессного эксперимента, который вы можете обсудить со своей командой на следующей ретроспективе и попробовать, не сильно рискуя.
Если у вас есть вопросы, задавайте в комментариях – буду рад помочь.

Автор: f0g

Источник

Поделиться

* - обязательные к заполнению поля