Вы когда-нибудь задумывались, какие именно задачи учитываются при расчёте velocity - и как на самом деле работают Velocity и Sprint Reports? Если нет, скорее всего ваши репорты не отражают реальную картину.

Вот 4 распространённых нюанса, которые могут серьёзно исказить ваши Velocity и Sprint Reports - и как моё приложение Multi-team Metrics & Retrospective может во многом автоматически устранить их:

1. Вы удаляете задачи из спринта только если они были действительно деприоритизированы?

Если вы вручную убираете незавершённые задачи из спринта (например, чтобы перенести в бэклог или следующий спринт) до его завершения вместо того, чтобы проследовать по workflow, который запускается после нажатия на кнопку 'Complete sprint', то Jira не посчитает их как "незавершённые" в Sprint Report. В результате ваш velocity окажется искусственно завышен. Удалять следует только те задачи, которые действительно деприоритизированны. Все остальные должны остаться и быть перенесены соответствующим образом.

2. Все ли выполненные задачи действительно входят в спринт?

Метрика Issues completed outside of this sprint в Sprint Report учитывает только те задачи, которые были завершены вне спринта И затем вручную добавлены в него. На практике многие команды закрывают задачи, но забывают их класть в спринт. Если вы проанализируете хотя бы квартал, то скорее всего найдёте несколько задач, которые были решены, но так и не вошли ни в один спринт. В результате Velocity и Sprint Reports не учитывают часть задач.

3. А как насчёт дубликатов?

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

4. Оцениваете ли вы повторно одну и ту же работу?

Пример: вы эстимируете Story в спринте, а позже появляется баг, созданный вашей же или другой командой - и он тоже получает эстимейт. Но на деле этот баг часто является продолжением той же задачи. В итоге работа считается дважды, а метрики искажаются лишними оценками.

Бонус: Путаница с Added Scope на ретроспективах

Если вы проводите анализ добавленного скоупа работ в активный спринт, то знаете, насколько сложно отличить действительно новую работу от ожидаемых дополнений - например, багов, выявленных при тестировании задач текущего спринта, или тех же дубликатов. В отчёте Sprint Report такие задачи отмечены звёздочкой (*), но отдельной метрики для них нет - приходится вручную анализировать каждую задачу.

Как вы проводите ретроспективы в своей команде? Используете Confluence или Miro с такими техниками, как ‘start, stop, continue’ или 4L? Как вы количественно оцениваете, стала ли ваша команда лучше за определённый период — будь то год или квартал? Полагаю, что никак, ведь извлекать данные из визуальных инструментов или вики-страниц, которые часто хаотично оформлены за целый год, — задача непростая.

Сколько раз вы помечали проблему как «TBD», которая в итоге оказывалась в бэклоге среди других таких же «TBD», которые позже было трудно приоритизировать? А если некоторые из этих «TBD» требовали одобрения от топ-менеджмента — например, на получение бюджета на увеличение вычислительных мощностей для быстрой компиляции или запуска тяжёлых тестов? Предполагаю, что в половине случаев вы оставляли попытки предоставить достоверные данные для обоснования бюджета или приоритизации задач.

Я тоже проходил через это, пока не реализовал решение для JIRA — Multi-team Metrics & Retrospective. Очевидно, что один из самых критически важных этапов ретроспективы — это анализ невыполненных коммитментов, что чаще всего означает незавершённый скоуп задач. Самый эффективный способ прогрессировать во времени я считаю анализ проваленных задач в каждом конкретном случае — согласно соответствующей метрике за конкретный период времени: будь то спринт, месяц, квартал, полугодие, год или релиз в PMIS (трекере задач).