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