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

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

Зачем нужно

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

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

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

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

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

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

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

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

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

Planning Poker
Planning Poker

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

Почему?

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

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

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

Требования:

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

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

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

Почему?

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

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

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

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

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

Карты из 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️⃣ — Задача уже выполнена.

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

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

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

Комментарии (8)


  1. fareloz
    25.05.2022 23:00

    Если не привязывать поинты к часам, то как понять сколько успеется за спринт? Ведь так или иначе сколько именно поинтов закинуть зависит от доступного времени каждого участника команды


    1. Malizia
      26.05.2022 00:36

      В теории должно быть все просто - набрали задач суммарно на N очков, где 1 очко - сложность базовой простой задачи. Прошли спринт, посчитали сложность спринта, M - количество завершенных задач. Если N равно M то продолжаем в том же духе, иначе пытаемся разобраться в причинах неверной оценки и переоцениваем размер следующего спринта. С ростом экспертизы команды сложность изначальной базовой задачи в 1 очко будет уменьшаться.

      На практике - сложно сравнивать задачи не переходя из попугаев в часы.


      1. msokolov Автор
        26.05.2022 01:19

        1) Тут не стоит забывать что в Story Points измеряются Пользовательские Истории(User Story), которые являются результатом совместного творчества.

        2) Попытка измерить в часах приведет к необходисоти указать время всех специалистов, участвующих в реализации:

        • 2ч - разработчик

        • 2ч - Тестировщик

        • 1ч - аналитик

        • 30 мин - Архитектор - и т. д.

        Также такие точные оценки приведет к большому расходу времени всей команды и не желанию чтото оценивать в дальнейшем.

        И потом - Можем ли мы приравнять 30 мин Архитектора к 2ч тестировщика?

        3) В общем - Story Point - это быстрая, относительная, командная оценка Историй, необходимая только для нужд Команды в планировании.


        1. Malizia
          26.05.2022 01:59
          +1

          Разработчик знает сколько он может сделать 1SP задач за спринт, разделить количество рабочих часов на количество задач - и у нас есть оценка базовой задачи разработчика в часах. Особой разницы между часами и SP нет.

          Сравнить часы тестировщика и архитектора тоже самое что сравнивать 1SP архитектора с 1SP тестировщика - можно, но смысла нет в виду несравнимых задач. Если пихать работу всех отделов в одну оценку, то будут сложности в оценке задач архитектора тестировщиками и наоборот, а это чревато частыми промахами в оценке задачи и размера спринта.

          Вот вопрос - если измерять в часах, то стоимость задачи равна суммарной стоимости всех отделов. А если в SP, то что является оценкой - максимальная оценка по отделам, или сумма оценок, или что-то другое? Теоретически, все в команде должны быть взаимозаменяемы и тогда максимальная оценка в SP имеет место быть, но на практике это сложно реализуемо и архитектор может только догадываться о стоимости тестирования, а разработчик о стоимости анализа.


          1. msokolov Автор
            26.05.2022 11:58

            1) SP - Это командная оценка, а не индивидуальная. Оценивать отдельные независимые задачи конкретного разработчика в SP - неработоспособная история. Часы - выглядят логичнее в этом случае - согласен.

            2) Сравнивать часы по разным компетенциям - ценности не имеет.

            3) Стоимость = Стоимость команды за спринт (часто - фикс) x Количество спринтов.

            А вот количество спринтов = Суммарная оценка всего беклога продукта / средняя производительность команды.

            Минус подхода в том что примерную оценку в $ можно получить после 2-4 спринтов.

            4) Теоретически, все в команде должны быть взаимозаменяемы - нет, команда должна быть просто кросс-функциональной, те в внутри команды достаточно навыков для работы над этим Проектом/Продуктом, и да - очень желательно иметь задублированные компетенции


    1. msokolov Автор
      26.05.2022 01:09

      1) Понять можно при условии стабильности состава команды, пусть даже участники будут выделены не на 100%. Имею ввиду, у менеджмента должна быть возможность выделять людей, т.е. - управлять составом команды. И да - с менеджментом бывают проблемы. Их стори поинты не решают.

      2) Потом - заранее, без накопления статистики по 2-4 спринтам, понять сколько брать на 1 спринт - невозможно.

      3) Имея показатели производительности за 4+ спринта и стабильно выделенную на 80%+ команду - мы можем довольно точно определять сколько можно взять на Спринт.


      1. dph
        26.05.2022 02:09
        +3

        Это верно только если:
        1) состав команды за 4 спринта не менялся (никто не уходил в отпуск, не болел и так далее)
        2) все задачи за эти спринты практически одинаковые и не содержат никакой новизны
        3) никто в команде не меняется (ни у кого нет личных причин снижать производительность, никто ничему не учиться - и так далее).

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


        1. msokolov Автор
          26.05.2022 11:43

          1) да, точность снижается, при отпусках, болезнях и прочих пропусках, но не критично, обычно просто надо больше Спринтов и команда находит свой уровень скорости в SP.

          2) Наооборот - имеет смысл использовать SP если задачи сложные, имеют большую неопределенность. При простых задачах - SP часто вообще использовать не требуется.

          3) Разделять цели команды\продукта - действительно надо. Тут у меня встречный вопрос - зачем работать на проекте если тебе кается не важным то что ты делаешь, и тебе все равно на общий результат. Это же IT, выбор есть.

          3) Обучение - часть работы, оно конечно в SP не оценивается, но сам факт что команда учится 10-20% времени всегда - учитывается при планировании.

          4) Оценки в SP не везде работают, это не универсальная пуля.