Почему ваши JIRA Velocity и Sprint Reports вероятно ошибочны
Вы когда-нибудь задумывались, какие именно задачи учитываются при расчёте velocity — и как на самом деле работают Velocity и Sprint Reports? Если нет, скорее всего ваши репорты не отражают реальную картину.
Вот 4 распространённых нюанса, которые могут серьёзно исказить ваши Velocity и Sprint Reports — и как моё приложение Multi-team Metrics & Retrospective может во многом автоматически устранить из них:
Вы удаляете задачи из спринта только если они были действительно деприоритизированы?
Если вы вручную убираете незавершённые задачи из спринта (например, чтобы перенести в бэклог или следующий спринт) до его завершения вместо того, чтобы проследовать по workflow, который запускается после нажатия на кнопку 'Complete sprint', то Jira не посчитает их как «незавершённые» в Sprint Report. В результате ваш velocity оказывается искусственно завышен. Удалять следует только те задачи, которые действительно деприоритизированны. Все остальные должны остаться и быть перенесены соответствующим образом.
Все ли выполненные задачи действительно входят в спринт?
Метрика Issues completed outside of this sprint в Sprint Report учитывает только те задачи, которые были завершены вне спринта И затем вручную добавлены в него. На практике многие команды закрывают задачи, но забывают их класть в спринт. Если вы проанализируете хотя бы квартал, то скорее всего найдёте несколько задач, которые были решены, но так и не вошли ни в один спринт. В результате Velocity и Sprint Reports не учитывают часть задач.
А как насчёт дубликатов?
Работа с дубликатами — это каверзная активность. Если не включить их в спринт — они теряются из поля зрения. Если включить — нужно строго следить, чтобы у них не было эстимейта, иначе они искажают метрики. В энтерпрайз компаниях иметь дюжину дубликатов не является чем-то особенным — это незамечаемый, но ощутимый источник искажений.
Оцениваете ли вы повторно одну и ту же работу?
Пример: вы эстимируете Story в спринте, а позже появляется баг, созданный вашей же или другой командой — и он тоже получает эстимейт. Но на деле этот баг часто является продолжением той же задачи. В итоге работа считается дважды, а метрики искажаются лишними оценками.
Бонус: Путаница с Added Scope на ретроспективах
Если вы проводите анализ добавленного скоупа работ в активный спринт, то знаете, насколько сложно отличить действительно новую работу от ожидаемых дополнений — например, багов, выявленных при тестировании задач текущего спринта, или тех же дубликатов. В отчёте Sprint Report такие задачи отмечены звёздочкой (*), но отдельной метрики для них нет — приходится вручную анализировать каждую задачу.
Всё это можно отслеживать вручную —, а можно позволить приложению сделать это за вас
Все эти проблемы можно решить с помощью процессов и постоянного ручного контроля. Но это требует времени, усилий и в конечном итоге является утомительным и подверженым ошибкам.
Это одна из причин почему я создал это приложение — чтобы убрать боль хотя бы вдвое, а возможно и больше.
Что делает приложение:
Автоматически включает Removed Scope в Final Scope и Uncompleted Scope (если задача не завершена).
Автоматически включает Scope Completed Outside в Final Scope и Completed Scope.
Автоматически исключает дубликаты из всех метрик — если они связаны с другой задачей в том же спринте.
Автоматически исключает задачи, прилинкованные как testing discovered (линк создаётся приложением автоматически), из метрик Added Scope (это отдельная метрика) и Re-estimated Scope.
Часть конфигурационного скрина:
Дэшборд вью:
Минимизируйте оверхед по сбору валдных командных перформанс метрик. Дайте аппу Multi-team Metrics & Retrospective взять нюансы на себя, чтобы вы сфокусировались на реальных улучшениях.
Habrahabr.ru прочитано 6847 раз
