Методология начисления Story Points.

Инструкция из 10 пунктов.

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

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

Зачем нужно

  • Планирование сроков реализации этапов продукта.
  • Оценка прогресса команды
  • При участии на PI Planning, не запланировать лишнего

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

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

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

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

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

Planning Poker

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

Почему?

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

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

Требования:

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

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

Почему?

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

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

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

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

Карты из 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️⃣ — Задача уже выполнена.
  • ♾️ — Очень большая история, нужно декомпозировать.
  • ❓ — Ничего не понятно. Добавляем конкретику и контекст.
  • ☕ — Пора прерваться 🙂

PDM & Scrum Master from Nizhny Novgorod https://t.me/agile4dev

PDM & Scrum Master from Nizhny Novgorod https://t.me/agile4dev