Методология начисления Story Points. Инструкция из 10 пунктов

Story Point (иногда Scrum Point) — относительная мера сложности или трудоёмкости элементов бэклога продукта.

Используется в Agile управлении продуктами.

Зачем нужно

• Планирование сроков реализации этапов продукта.

• Оценка прогресса команды

• При Планировании спринта или участии на PI Planning — не запланировать лишнего

Если отвечать утилитарно — оценки(Estimate) нужны для быстрого и реалистичного планирования объема работы на спринт и построения BurnDown (BurnUP) диаграммы или Velocity Chart.

Почему лучше не приравнивать Story Point к Нормо-Часам, трудо-дням, FTE и т.д.

• Велик соблазн сравнения команд между собой

• Есть риск закрытия ЗП или Контрактов исходя из Нормо-часов.

Оба эти фактора не добавляют точности, т.к. команды, осознанно или нет, начнут накручивать оценки.

Методология оценки.

1. Собирается команда в полном составе.

Почему?

• Чтобы сформировать ответственность за оценки.

• Чтобы учесть все нюансы, нужны все компетенции.

2. Открываем бэклог продукта

Требования:

• Беклог Отранжирован по бизнес ценности

• У каждого элемента есть — Критерии приёмки(AC).

Идеальный случай — иметь DoR (Критерии готовности к взятию в работу, Definition of Ready). Но обычно на старее продукта его нет.

Почему?

• Размытые границы PBI вряд ли позволят дать достаточно точную оценку для нужд планирования. Также разные члены команды могут заложить разный смысл в элементы, что тоже плохо отразиться на производительности команды.

• Нечёткие границы PBI раздувают время проведения оценки.

3. Берём Карты с числами Фибоначчи или чем то похожим.

Подойдёт Miro, или любой другой другой инструмент, позволяющий голосовать анонимно.

Есть такой вариант:

Почему?

• Чтобы не тратить время на споры — что это 5 или 5,25.

• Если открыто голосовать — будут повторять оценку за первым.

• Больше 100 — сильно теряется точность.

4. Выбираем задачу на 1 SP

• Выбираем маленькую и понятную максимальному числу участников команды.

• Если нет ни у кого принципиальных возражений — принимаем задачу за 1 Story Point

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

5. Зачитываем верхний неоценённый элемент PBI из Бэклога

• Кто — например PO, не принципиально.

• Полностью, включая Критерии приёмки.

Почему:

• Не все помнят задачи досконально, еще и меняется все постоянно.

6. Каждый член команды даёт свою оценку “в закрытую”

Почему:

• Закрытость позволяет минимизировать влияние чужого мнения.

7. Команда “переворачивает” карточки

• Оценки всех членов команды равнозначны.

Почему:

• Так проще и быстрее.

• Формируется чувство общности(коллектива).

8. Оцени сходятся

Оцени различаются не больше чем на 3 шага

• Ставим большую из “средних” карточек.

• Никаких расчётов и средних арифметических. Просто число.

?Переходим на Пункт 5.

Почему:

• Так быстрее, точность при этом на масштабе не страдает.

9. Оцени НЕ сходятся

Оцени различаются на 4 шага и более.

• Даём слово 2–3м участникам поставившим самые полярные оценки.

• Каждый аргументировано отвечает на вопрос — Почему именно оценка Х ?

? Переходим на Пункт 6.

Почему:

• Большие разногласия — реальный риск получить ? спринте.

10. Пункт со ***

• 0️⃣ — Задача уже выполнена.

• ♾️ — Очень большая история, нужно декомпозировать.

• ❓ — Ничего не понятно. Добавляем конкретику и контекст.

• ☕ — Пора прерваться ?