Velocity – это скорость работы команды. Как правило, используется усредненная за 3 прошедших спринта.

4 частых вопроса про его вычисление (тут используется термин Product Owner, но это может быть любой другой похожий руководитель, как бы он ни назывался в конкретной ситуации):

  1. Если у нас есть задачка на 4 SP, и она по уверениям разработчика закончена на 90%, то учитывается ли она в спринте? Хотя бы частично, мы же работали и почти доделали? Нет, не учитывается, т.к. задача (story) – это уже и так минимально видимая ценность для пользователей: если она не сделана, то и ценности нет, а значит и учитывать нечего. Если оказалось, что все-таки можно разбить, то это урок на будущее, текущие задачи не разбиваются.
  2. После начала разработки стало понятно, что задачка сложнее, чем казалось изначально. Можно ли поменять оценку? Нет, т.к. оценка для улучшения прогнозов на будущее: с большой вероятностью мы опять так же ошибемся и это уже будет заложено в нашей скорости. Не ошибемся – скорость увеличится, тоже хорошо, что мы учимся на ошибках и как команда становимся лучше, но это нужно доказать безошибочностью в будущем.
  3. После начала разработки стало понятно, что задачка сильно сложнее, чем казалось изначально. Например, месяц вместо 1 дня. Что делать? Так же не менять оценку? Нет, задачку нужно отменять, тогда она добавляет 0 SP в спринт. Возможно, если это что-то важное, то и весь спринт отменять (перезапускать). Пусть Product Owner уже заново декомопозирует и приоритезует, тогда к новым задачкам будут делаться оценки.
  4. Измерять ли баги в SP? Как учитывать сколько времени мы их будем исправлять – мы же заранее не знаем? Баги не измеряются в SP, т.к. это не story по определению. Product Owner определяет включать баги в текущий спринт или нет. Если баг включен, то он по приоритетам выше любой stories (прерывать или нет текущую stories – отдельный момент). По сути, это остатки от каких-то предыдущих story, которые нас тормозят. Правильно, что они снижают скорость тем, что мы их не учитываем. Они уже учетны в SP тех задач, которые делали раньше. Другими словами не нужно стараться “закрыть” задачи, если мы понимаем, что там еще много багов: они быстро вернутся и скажутся на скорости. Какие-то всплески компенсируются тем, что мы усредняем velocity для целей понимания сколько stories мы можем взять в спринт.
  5. Мы хотим включить несколько багов спринт при его планировании. Это может занять чуть ли не половину спринта. Мы их всё так же не учитываем? Тут принцип такой же как и со stories: если это обычные баги, то не учитываем, если что-то экстраординарное (на месяц+), то становится story со всеми вытекающими последствиями. Да, скорость просядет и это адекватно, т.к. значит раньше она была завышенной. Как определиться сколько именно тогда задач брать в спринт? По консенсусу команды: спросить “первые 8 сделаем”? Да. А 20? Уже вряд ли. 15? Да, должно получиться, но больше уже вряд ли. На этом и останавливаемся.
  6. Но это же старые баги еще от другой команды, а мы на это тратим время. Давайте их учитывать в спринте. Нет, т.к. интересует не условная “чистая” производительность команды, а сколько фич она может сделать. Отдельные всплески багов усредняются скоростью за 3 спринта.