Обычно пользовательские требования выполняются не поштучно, а пакетами. Это связано со сложной технологией разработки, снижением потерь на перетестирование, а также с тем, что пользователям не интересны штучные требования, им интересен осязаемый результат.
По этой причине, в отличие от таск-менеджеров, срок завершения нескольких требований определяется концом итерации или релиза, а не конкретной датой для каждого требования. При планировании разработки мы выделяем несколько итераций или релизов, раскидываем по ним требования и контролируем сроки завершения целиком итерации или релиза.
Однако, бывают исключения и некоторые требования важно выполнить к определенной дате, вне зависимости от того, в какой релиз или итерацию оно включено. Для этого у первичного требования (пожелания или истории) есть поле "Сроки", в котором явно можно указать дату, к которой необходимо выполнить требование. Для задач также есть поля "Начать" и "Завершить", которые позволяют точечно управлять датами начала и завершения некоторых особенных задач.
Информация о сроках по требованиям и задачам отображается в следующих модулях:
Для удобства, все пользователи по умолчанию получают отчет о ближайших задачах по своим проектам. Отключить это уведомление можно в профиле пользователя.
Все самые срочные задачи всегда отображаются в верхней части приложения - в списке ближайших задач.
У пожеланий, заявок, доработок есть отдельный атрибут "Оценка завершения". Значение будет соответствовать сроку, если для данного требования явно указан требуемый срок завершения. Если это требование включено в итерацию или релиз, то расчетная дата их завершения будет использоваться в качестве оценки даты завершения требования. В остальных случаях оценка завершения вычисляется на основе скорости команды и оценки трудоемкости данного требования.
Последовательный процесс (Kanban) ставит целью ускорить прохождение требования от начала технологической цепочки до ее окончания. Основной метрикой процесса в этом случае является пропускная способность вашей команды. Измерять ее можно в среднем количестве часов, необходимых для реализации требования. Чем меньше эта величина, тем эффективнее работает ваш процесс и у команды выше производительность. Такую величину называют - среднее время цикла.
Чтобы проанализировать более детальную картину - сколько времени требование (или задача) провели на каждом этапе технологического процесса - можно использовать вкладку "Жизненный цикл" на форме просмотра или редактирования задачи/пожелания. В отчете "Детализация времени цикла" можно проанализировать длительность этапов для набора пожеланий или пользовательских историй.
Используйте “График распределения времени цикла историй”, отображающий зависимость количества выполненных историй от длительности их времени цикла, выраженной в днях
При использовании "параллельного процесса", например, Scrum или Scrumban (в части нового релиза), используется основная метрики Agile - скорость команды. Она показывает, какой объем работы может выполнить команда за одну итерацию (спринт). Объем работы выражается в количестве требований (если они однотипные и мелкие), либо в оценках сложности, например, Story Points.
Скорость команды может меняться от спринта к спринту. Непрерывное увеличение среднего говорит о повышении эффективности работы команды. Для отслеживания показателя используется отчет "Скорость разработки". На нем сопоставляются плановая и фактическая скорости.
Для контроля за сроками спринта используется график сжигания работы (Burndown Chart):
Желтая линия показывает запланированный объем работ. Красная - требуемый объем незавершенной работы на каждый день спринта. Зеленая - фактически незавершенный объем работы. Синяя - прогноз завершения спринта. Если зеленая линия все время находится под красной, то спринт вы завершите вовремя.