В проектах Scrum оценка проводится всей командой во время совещания по планированию Sprint. Цель оценки - рассмотреть истории пользователей для спринта по приоритету и способностью команды доставить в течение временной шкалы спринта.

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

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

Размер Приращения Продукта оценивается с точки зрения Точек Истории Пользователя. Как только размер определяется, усилия оцениваются с помощью прошлых данных, т. Е. Усилий на точку пользовательской истории, называемой Productivity.

Методы оценки Scrum

Оценка Scrum User Stories относится к степени сложности для каждой из Историй Пользователя. Для оценки степени сложности используется конкретный масштаб.

Существует несколько типов шкал, которые используются в оценке Scrum. Ниже приведены некоторые примеры -

  • Цифровой размер (от 1 до 10)
  • Размеры футболки (XS, S, M, L, XL XXL, XXXL)
  • Последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 21, 34 и т. Д.)
  • Породы собак (чихуахуа, ........., дог)

Метод оценки обычно выбирается таким образом, что вся команда схватки знакома и удобна с значениями шкалы. Наиболее часто используемым и популярным методом является Planning Poker, который основан на последовательности Фибоначчи.

Планирование оценки

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

Планирование Покер играет с колодой карт. Поскольку последовательность Фибоначчи используется, карты имеют числа - 1, 2, 3, 5, 8, 13, 21, 34 и т. Д. Эти числа представляют собой Точки Истории. Каждая оценка имеет колоду карт. Номера на карточках должны быть достаточно большими, чтобы быть видимыми для всех членов команды, когда один из членов команды держит карту.

В качестве модератора выбирается один из членов команды. Модератор читает описание пользовательской истории, для которой выполняется оценка. Если у оценщиков есть какие-либо вопросы, Ответчик продукта отвечает им.

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

В первом раунде очень вероятно, что оценки меняются. Высокие и низкие оценки объясняют причину их оценок. Следует проявлять осторожность, чтобы все обсуждения были предназначены только для понимания, и ничто не должно приниматься лично. Модератор должен обеспечить то же самое.

Команда может обсудить историю и свои оценки в течение нескольких минут.

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

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

Преимущества планирования оценки

Планирование покера сочетает в себе три метода оценки:

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

Analogy : Analogy Estimation использует сравнение пользовательских историй. Оценочная статистика пользователей сравнивается с аналогичными пользовательскими историями, реализованными ранее. Это приводит к точным результатам, поскольку оценка основана на проверенных данных.

Дезагрегация : дезагрегация Оценка производится путем разбиения пользовательской истории на более мелкие, легко оцениваемые пользовательские истории. Истории пользователей, которые должны быть включены в Sprint, обычно находятся в диапазоне от двух до пяти дней для разработки. Следовательно, Истории пользователей, которые, возможно, занимают больше времени, должны быть разделены на более мелкие Случаи использования. Этот подход также гарантирует, что будет много историй, сопоставимых.