Почему ваши 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 в спринте, а позже появляется баг, созданный вашей же или другой командой - и он тоже получает эстимейт. Но на деле этот баг часто является продолжением той же задачи. В итоге работа считается дважды, а метрики искажаются лишними оценками.
https://habr.com/ru/articles/908494/
#jira #scrum #scrum_master #kanban #agile #velocity #jira_plugin #safe #less #project_manager