Как оценивать сроки разработки в Scrum-команде? Используем Story Points, Burndown, Velocity & Capacity

Как оценивать сроки разработки в Scrum-команде? Используем Story Points, Burndown, Velocity & Capacity

Разберем подход оценки сроков решения задач в Scrum-команде, через Velocity & Capacity.

Зачастую встречаются ситуации, в которых команды разработки не могут оценить сроки, или оцененные сроки очень часто нарушаются.

Справедливости ради стоит сказать что многим командам это на самом деле не очень то и нужно. Спокойно работают по OKR и не парятся.

Однако у кого то редко, а у кого-то часто возникают такие задачи, по которым нужно назвать срок. И не просто назвать срок, а еще уложиться в него.

Плаваем в методологиях

Вот тут то и начинается плавание в методологиях. Waterfall как правило не помогает, и сроки которые даются после такой оценки — в 90% случаев пролетают. Иногда даже в 10 раз. Планировали закончить через месяц, а в итоге ушел год. Клиенты в шоке.

Далее переключаемся в Scrum, находим интересной идею что надо считать стори-поинты через Фибоначи, и тут часто ждет засада. Однако не все так грустно. Если понимать как это работает, то можно и посчитать. Другой вопрос что это не бесплатно.

Зачем и как считать сторипоинты? Что такое Velocity?

Давайте начнем с вопроса попроще. Зачем и как считают сторипоинты? И почему не оценку в трудочасах?

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

Для начала можно представить некую среднюю команду разработки из 7 человек. Которая как-то декомпозирует задачи и выполняет их.

Если вы соберете статистику, то увидите что каждый месяц эта команда будет закрывать примерно одинаковое количество задач. Скажем 100 (± 20) задач.

Диаграмма сжигания (burndown chart) будет примерно одинаковой от месяца к месяцу.

Эта штука будет работать только если команда умеет хорошо декомпозировать задачи. На достаточно малые сценарии.

И вот тут то и встречается первая засада. Многие это не умеют. Чтобы команда понимала стоит декомпозировать задачу дальше или нет, она должна научиться давать задаче баллы. Типа мелкая или большая? Вот здесь нам и нужны сторипоинты и числа Фибоначи.

Скажем мелкая задача которая ничего не стоит это 1 (сходить за кофе), а если что то надо поделать то это 2 (запилить кнопочку или фантик на пару часиков), если задача займет день работы то это 3, а если 2 дня то это 5, а неделю это 8, а если больше недели то это 13.

Если задачу оценили как 13 (больше недели), это сигнал что надо бы ее распилить. В каких то командах пилят задачи если она занимает неделю. Это на вкус и цвет. Главное без фанатизма.

Через 3-4 спринта, можно будет посчитать сколько в среднем закрывается очков в нашей команде за 1 спринт. Эта метрика называется Velocity.

Предположим наш Velocity через 3 месячных спринта оказался равен 230 баллов (сторипоинтов). Это средняя скорость команды. Это значит что за 1 месяца ваша команда в среднем делает 230 баллов.

Это надо запомнить и двигаться дальше…

Если ваш Velocity прыгает от спринта к спринту, значит вы что то делаете не так. Если все делать правильно он очень стабильный.

Причины скачков Velocity могут быть следующие:

  1. В вашей команде меньше 3 человек или больше 10
  2. У вас нет Scrum-мастера или тот что есть туповат
  3. Вам это не очень то и надо, потому все просто имитируют оргазм скрам
  4. Что-то еще чего я не встречал

Теперь нам нужно найти Capacity по задаче

Вот тут большинство команд буксуют. Какие то даже не доходят или ломаются. А без этой метрики — срок назвать нельзя 🙂 И все ваши танцы со сторипоинтами и подсчет велосити — это ИБД.

Здесь важно понять ряд ключевых аспектов

  1. Как правило, в большинстве ситуаций бэклог состоит из сотен задач
  2. Но срок можно назвать лишь по нескольким задачам
  3. Точнее дату можно назвать лишь по 1 крупной задаче (проекту, эпику)
  4. Если надо называть срок сразу у 3 или 4 задач, то можно называть лишь примерные месяца завершения
  5. Если вы хотите назвать срок по 10 крупным задачам — вам никто и ничто не поможет. Лучше уйти из разработки в таксисты.
  6. В идеале, всегда фокусировать силы на 1 крупной задаче. Особенно если эта задача важна Клиенту и от ее результата зависит судьба компании.

Вот мы взяли 1 крупную задачу, которая возможно займет 2 месяца работы, а может быть пол года? Как это понять?

  1. Сначала надо эту задачу декомпозировать на подзадачи по методу ВИСИ.
  2. Затем выписать все задачи в бэклог
  3. Задачам дать оценку в баллах (да да те что сторипоинты и фибоначи)

Так вы получите Capacity по задаче. Предположим Capacity по задаче получилось 550 баллов.

Прогнозируем срок по задаче

Теперь мы знаем месячный Velocity команды и Capacity по большой задаче.

550 делим на 230 — получаем примерно 2 месяца. 2 месяца или 2 месячных спринта уйдет у команды чтобы сделать задачу.

Тут стоит заметить, что для правильной декомпозиции 1 большой задачи иногда надо потратить 1-2 дня работы всей команды. Это одна из причин по которой никто это не делает.

Если задача оч большая, то на ее декомпозицию и оценку уйдет неделя или месяц. Команда время от времени будет возвращаться к задаче и добивать декомпозицию с оценкой.

капитан Очевидность

Что делать если мы понимаем что в срок не укладываемся?

Договариваться с Клиентом — обрезать задачу. Убирать что-то чем можно пожертвовать. При умелом владении искусством переговоров в 99% случаев это реально.

Когда этот подход работает, а когда нет?

Два примера когда это работает:

Президент крупной корпорации заявил о том что в июле выпустят новую версию своего продукта. Рынок взорвался. Новость наделала шума. А потом донесли срок до команды, команда сказала что это не реально. На кону стояла судьба всей корпорации и голова президента. В этой ситуации подход сработал.

пример взят из книги «красный скрам»

Делали сайт банка, был ребрендинг, к определенной дате по всей стране должна была запускаться рекламная кампания с новыми брендом. К этой дате сайт надо было запустить.

Декомпозировали весь сайт на разделы и подразделы. Оценили, в целом попали, но под конец часть функционала пришлось все таки отрезать.

из личного опыта

Когда это не работает?

  • В ситуации когда все срочно
  • Когда надо назвать срок по 33 задачам
  • Когда вся срочность вымышленная и никто не готов серьезно вкладываться в качественную декомпозицию и оценку задач
  • Когда в команде нет тех кто достаточно хорошо знаком с методом оценки сроков через Story point, Velocity & Capacity.
Информация была полезна для вас?

Расскажите пожалуйста что мы можем улучшить?

оцените контент и участвуйте в выборе трендов