Понимание метрик Scrum: Velocity, Throughput и Cycle Time
Изучите основные метрики Scrum, такие как Velocity, Throughput и Cycle Time. Узнайте, что они измеряют, как эффективно их использовать и каких распространенных ошибок следует избегать для повышения производительности команды и улучшения прогнозирования.
Многие команды что-то измеряют. Это хорошо. Измерения помогают понять, что происходит, и предсказать, что может произойти дальше. Но не все метрики одинаковы, и некоторые из них часто используются неправильно. Для Scrum-команд понимание Velocity, Throughput и Cycle Time является ключом к улучшению процесса поставки ценности. Эти метрики, инструменты. Используйте их для инспекции и адаптации, а не для оценки или сравнения.
Velocity: что это такое и чем не является
Velocity измеряет количество элементов Product Backlog, выполненных Scrum-командой за Sprint. Обычно она выражается в Story Points или количестве элементов. Например, команда может выполнить 30 Story Points в одном Sprint, а затем 35 в следующем. Это дает команде историческое среднее значение выполненной работы за Sprint. Это полезный вход для Разработчиков при планировании будущих Спринтов, помогающий им прогнозировать, сколько работы они могут реально взять в Sprint. Это также вход для Product Owner для долгосрочного прогнозирования.
Однако Velocity, это внутренняя метрика команды. Она специфична для одной команды, ее Definition of Done и ее практик оценки. Вы не можете сравнивать Velocity разных команд. Делать это все равно что сравнивать яблоки с апельсинами. Это не дает полезной информации и часто приводит к неправильным стимулам. Velocity также не должна использоваться в качестве целевого показателя производительности. Если вы скажете команде увеличить ее Velocity, они, скорее всего, завысят оценки Story Points, не поставляя при этом больше реальной ценности.
Throughput: более простая метрика
Throughput проще, чем Velocity. Это количество элементов Product Backlog, выполненных за определенный период. Например, команда может выполнить 7 элементов в одном Sprint, 8 в другом и 6 в третьем. Эта метрика менее абстрактна, чем Velocity, потому что она не зависит от субъективных единиц оценки, таких как Story Points. Она просто подсчитывает выполненные элементы.
Throughput может быть особенно полезна для команд, у которых элементы имеют одинаковый размер или которые разбили свою работу на очень маленькие, схожие по размеру части. Она предлагает прямой подсчет поставленной работы, что делает ее легкой для понимания и отслеживания с течением времени. Как и Velocity, Throughput помогает в прогнозировании и понимании пропускной способности команды. Это по-прежнему внутренняя метрика команды, не предназначенная для сравнения.
Cycle Time: фокус на потоке
Cycle Time измеряет общее время, необходимое для того, чтобы элемент Product Backlog прошел путь от начала работы над ним до его завершения. Это продолжительность с момента, когда Разработчик берет элемент в работу ('in progress'), до момента, когда он соответствует Definition of Done. Например, если работа над элементом начинается в понедельник и заканчивается в пятницу, его Cycle Time составляет пять дней.
Более низкий Cycle Time означает более быструю поставку. Эта метрика отлично подходит для выявления узких мест и улучшения потока работы. Если Cycle Time высок, это часто указывает на задержки в проверке, тестировании или передаче. Сокращение Cycle Time означает, что ценность быстрее доходит до пользователей, а циклы обратной связи сокращаются. Это мощная метрика для постоянного улучшения.
Когда какую метрику использовать
Выбор метрики зависит от того, что вы хотите понять и улучшить:
- Используйте Velocity или Throughput для планирования Sprint и прогнозирования релизов: Чтобы помочь Разработчикам понять, сколько работы они могут взять в Sprint, и для Product Owner, чтобы прогнозировать, когда более крупный набор функций может быть готов.
- Используйте Cycle Time для выявления узких мест и улучшения потока: Чтобы понять, сколько времени требуется для поставки отдельных элементов, и определить области, где работа застревает или задерживается.
- Используйте все из них для прозрачности и инспекции: Чтобы предоставить данные для обсуждения Scrum-командой во время Sprint Retrospective, выявить тенденции и сформулировать эксперименты для улучшения.
Распространенные ошибки, которых следует избегать
Рассматривать эти метрики как показатели производительности для отдельных лиц или для сравнения команд, это ошибка. Это приводит к манипулированию системой, а не к реальному улучшению. Сосредоточьтесь на тенденции с течением времени, а не на отдельных точках данных. Стабильная Velocity или Throughput позволяет более надежно прогнозировать. Уменьшающийся Cycle Time указывает на повышение эффективности и улучшение потока. Используйте эти метрики для повышения прозрачности и поддержки самоуправления Scrum-команды и усилий по постоянному улучшению, а не для контроля над ними.