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️⃣ — Задача уже выполнена.
♾️ — Очень большая история, нужно декомпозировать.
❓ — Ничего не понятно. Добавляем конкретику и контекст.
☕ — Пора прерваться ????
fareloz
Если не привязывать поинты к часам, то как понять сколько успеется за спринт? Ведь так или иначе сколько именно поинтов закинуть зависит от доступного времени каждого участника команды
Malizia
В теории должно быть все просто - набрали задач суммарно на N очков, где 1 очко - сложность базовой простой задачи. Прошли спринт, посчитали сложность спринта, M - количество завершенных задач. Если N равно M то продолжаем в том же духе, иначе пытаемся разобраться в причинах неверной оценки и переоцениваем размер следующего спринта. С ростом экспертизы команды сложность изначальной базовой задачи в 1 очко будет уменьшаться.
На практике - сложно сравнивать задачи не переходя из попугаев в часы.
msokolov Автор
1) Тут не стоит забывать что в Story Points измеряются Пользовательские Истории(User Story), которые являются результатом совместного творчества.
2) Попытка измерить в часах приведет к необходисоти указать время всех специалистов, участвующих в реализации:
2ч - разработчик
2ч - Тестировщик
1ч - аналитик
30 мин - Архитектор - и т. д.
Также такие точные оценки приведет к большому расходу времени всей команды и не желанию чтото оценивать в дальнейшем.
И потом - Можем ли мы приравнять 30 мин Архитектора к 2ч тестировщика?
3) В общем - Story Point - это быстрая, относительная, командная оценка Историй, необходимая только для нужд Команды в планировании.
Malizia
Разработчик знает сколько он может сделать 1SP задач за спринт, разделить количество рабочих часов на количество задач - и у нас есть оценка базовой задачи разработчика в часах. Особой разницы между часами и SP нет.
Сравнить часы тестировщика и архитектора тоже самое что сравнивать 1SP архитектора с 1SP тестировщика - можно, но смысла нет в виду несравнимых задач. Если пихать работу всех отделов в одну оценку, то будут сложности в оценке задач архитектора тестировщиками и наоборот, а это чревато частыми промахами в оценке задачи и размера спринта.
Вот вопрос - если измерять в часах, то стоимость задачи равна суммарной стоимости всех отделов. А если в SP, то что является оценкой - максимальная оценка по отделам, или сумма оценок, или что-то другое? Теоретически, все в команде должны быть взаимозаменяемы и тогда максимальная оценка в SP имеет место быть, но на практике это сложно реализуемо и архитектор может только догадываться о стоимости тестирования, а разработчик о стоимости анализа.
msokolov Автор
1) SP - Это командная оценка, а не индивидуальная. Оценивать отдельные независимые задачи конкретного разработчика в SP - неработоспособная история. Часы - выглядят логичнее в этом случае - согласен.
2) Сравнивать часы по разным компетенциям - ценности не имеет.
3) Стоимость = Стоимость команды за спринт (часто - фикс) x Количество спринтов.
А вот количество спринтов = Суммарная оценка всего беклога продукта / средняя производительность команды.
Минус подхода в том что примерную оценку в $ можно получить после 2-4 спринтов.
4) Теоретически, все в команде должны быть взаимозаменяемы - нет, команда должна быть просто кросс-функциональной, те в внутри команды достаточно навыков для работы над этим Проектом/Продуктом, и да - очень желательно иметь задублированные компетенции
msokolov Автор
1) Понять можно при условии стабильности состава команды, пусть даже участники будут выделены не на 100%. Имею ввиду, у менеджмента должна быть возможность выделять людей, т.е. - управлять составом команды. И да - с менеджментом бывают проблемы. Их стори поинты не решают.
2) Потом - заранее, без накопления статистики по 2-4 спринтам, понять сколько брать на 1 спринт - невозможно.
3) Имея показатели производительности за 4+ спринта и стабильно выделенную на 80%+ команду - мы можем довольно точно определять сколько можно взять на Спринт.
dph
Это верно только если:
1) состав команды за 4 спринта не менялся (никто не уходил в отпуск, не болел и так далее)
2) все задачи за эти спринты практически одинаковые и не содержат никакой новизны
3) никто в команде не меняется (ни у кого нет личных причин снижать производительность, никто ничему не учиться - и так далее).
В реальности, конечно, эти критерии не срабатывают - поэтому оценка в SP не работает.
Собственно, даже автор идеи SP в твиттере извинялся за свою идею, так как ничего хорошего из нее не получилось.
msokolov Автор
1) да, точность снижается, при отпусках, болезнях и прочих пропусках, но не критично, обычно просто надо больше Спринтов и команда находит свой уровень скорости в SP.
2) Наооборот - имеет смысл использовать SP если задачи сложные, имеют большую неопределенность. При простых задачах - SP часто вообще использовать не требуется.
3) Разделять цели команды\продукта - действительно надо. Тут у меня встречный вопрос - зачем работать на проекте если тебе кается не важным то что ты делаешь, и тебе все равно на общий результат. Это же IT, выбор есть.
3) Обучение - часть работы, оно конечно в SP не оценивается, но сам факт что команда учится 10-20% времени всегда - учитывается при планировании.
4) Оценки в SP не везде работают, это не универсальная пуля.