Пять действительно нужных agile-показателей KPI

Agile metrics are quantitative measures used to track the progress, quality, and effectiveness of agile teams and projects. Common metrics include velocity, lead time, cycle time, burndown charts, and cumulative flow diagrams.

These metrics help teams identify bottlenecks, forecast delivery, and drive continuous improvement. For example, tracking velocity allows teams to predict how much work they can complete in future sprints, while monitoring cycle time highlights areas for process optimization.

What is a KPI in Agile?

A KPI (Key Performance Indicator) in Agile is a specific metric used to measure the success of a team or project against defined goals. KPIs might include customer satisfaction, defect rates, or time to market, depending on what’s most important to the organization. Selecting the right KPIs ensures that teams stay focused on delivering value and achieving strategic objectives. For example, a team might track the number of critical bugs resolved per sprint as a KPI to improve product quality and customer experience.

«Готовый» продукт — какой он? Это актуальный продукт, созданный в нужное время для подходящего рынка. Неукоснительное следование программе подразумевает сбор и анализ определенных данных в ходе работы. В рамках любой agile-программы важно отслеживать как бизнес-показатели, так и метрики Agile. Первые показатели помогают понять, насколько решение удовлетворяет потребностям рынка, а вторые — позволяют оценить разные аспекты процесса разработки.

Бизнес-показатели программы должны основываться на ее дорожной карте.

Для каждой инициативы на дорожной карте нужно предусмотреть несколько ключевых показателей эффективности (KPI), которые соотносятся с целями программы. Кроме того, нужно задать критерии успешности для каждого требования к продукту, например доля конечных пользователей, внедривших продукт, или покрытие кода автоматическими тестами (в процентах). Эти критерии успешности находят выражение в agile-показателях программы. И чем больше команды учатся, тем лучше они могут приспосабливаться и развиваться.

Диаграмма Burndown для спринта

Команды Scrum дробят процесс разработки на спринты с фиксированной продолжительностью. На начальной стадии спринта команда дает прогноз, какой объем работы она сможет выполнить за спринт. Затем ход выполнения работы в спринте отслеживается с помощью диаграммы Burndown. Ось X отражает время, а ось Y — объем работы, который осталось завершить, в очках оценки сложности или часах. Команда стремится выполнить весь запланированный объем работы к концу спринта.

Если показатели команды всегда соответствуют прогнозу, методика Agile может очень быстро набрать популярность в организации. Но не спешите выдавать желаемое за действительное и не объявляйте об успешном выполнении задачи раньше времени. Такой подход может принести плоды в краткосрочной перспективе, однако он помешает дальнейшему обучению и совершенствованию.  

Узнайте, как использовать диаграммы Burndown в Jira

Сгорание релиза и эпика

С помощью диаграмм Burndown для эпиков и релизов (или версий) отслеживается ход выполнения большего объема работы, чем с помощью диаграмм Burndown для спринтов. Ими могут руководствоваться при разработке команды, применяющие как Scrum, так и Kanban. В спринте (у команд Scrum) могут содержаться рабочие задачи из нескольких эпиков и версий сразу, поэтому важно отслеживать прогресс отдельных спринтов, равно как и эпиков и версий.

Расширение области проекта — это внесение дополнительных требований в уже скомпонованный проект. Например, если команда должна поставить новый веб-сайт для компании, расширением области проекта может считаться запрос новых функций после того, как были намечены первоначальные требования. С расширением области проекта в ходе спринта мириться не стоит, а вот в рамках эпиков или версий это явление логически вытекает из самой сути agile-разработки. Наблюдая, как команда выполняет рабочие задачи в проекте, владелец продукта может менять объем работы в зависимости от сделанных им выводов. Диаграммы Burndown для эпиков и релизов — это надежный источник информации обо всех изменениях в объеме работы в рамках эпика и версии.

Скорость команды

Скорость команды — это средний объем работы, который Scrum-команда выполняет за спринт, измеренный в очках оценки сложности или часах. Этот показатель используется при прогнозировании. С его помощью владелец продукта может предположить, как быстро команда справится с задачами из бэклога, поскольку в отчете учитывается объем запланированной и выполненной работы за несколько итераций. Чем больше итераций, тем точнее прогноз.

Предположим, что владелец продукта хочет выполнить работу из бэклога с оценкой сложности 500 очков. Известно, что команда разработчиков, как правило, за каждую итерацию выполняет работу с оценкой сложности 50 очков. Владелец продукта имеет все основания полагать, что команда справится с поставленными задачами примерно за 10 итераций.

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

Скорость каждой команды уникальна. Если скорость команды А равна 50, а скорость команды Б — 75, это не значит, что производительность команды Б выше. В каждой команде складываются свои принципы оценки сложности работы, поэтому и скорость работы у каждой команды тоже будет своя. Не пытайтесь сравнивать скорости разных команд. Оценивайте количество усилий и результаты работы команды исходя из ее собственной трактовки оценки сложности. 

Контрольный график

Контрольные графики позволяют сосредоточиться на времени цикла отдельных задач — на времени, которое в сумме требуется для перемещения задачи со стадии «В процессе» на стадию «Готово». Небольшое время цикла, скорее всего, означает высокую производительность команды, а команды, для которых характерно стабильное время цикла при выполнении многих задач, более предсказуемы в плане поставки результатов работ. Время цикла — это основной показатель для оценки команд Kanban, но оптимизация времени цикла может быть целесообразна и для команд Scrum.

Измеряйте время цикла, чтобы знать, как усовершенствовать процессы команды эффективно и разными способами: результаты изменений заметны практически сразу, поэтому можно без промедления вносить дополнительные поправки. Конечная цель — добиться стабильного и короткого времени цикла независимо от типа работы (добавление новой функции, ликвидация технического долга и т. д.).

Сводная диаграмма процесса

Линии на сводной диаграмме процесса, которые читаются слева направо, должны быть в идеале лишены резких перепадов. Подъемы или пробелы на какой-либо линии одного цвета — признак дефицита или проблемных мест. При обнаружении подобных явлений следует попытаться сгладить цветные полосы на диаграмме.

Good metrics aren't limited to the reports discussed above. For example, quality is an important metric for agile teams and there are a number of traditional metrics that can be applied to agile development:

• How many defects are found:

  • during development?

  • after release to customers?

  • by people outside of the team?

• How many defects are deferred to a future release?

• How many customer support requests are coming in?

• What is the percentage of automated test coverage?

Agile teams should also look at release frequency and delivery speed. At the end of each sprint, the team should release software out to production. How often is that actually happening? Are most release builds getting shipped? In the same vein, how long does it take for the team to release an emergency fix out to production? Is release easy for the team or does it require heroics?

Find insights in context

Insights are a great tool for teams to access metrics when they need them: during sprint planning, checking in at the daily standup, or optimizing delivery. You can find insights in the upper right-hand corner of the board, backlog, and deployments view of Jira.

Insights give a visual snapshot of the following metrics:

• Sprint progress

• Issue type breakdown

• Sprint commitment

• Deployment frequency

• Cycle time

Use these metrics to continuously optimize team performance. Learn more about insights.

The success of an Agile project is measured by evaluating both quantitative metrics and qualitative outcomes, such as delivering value to customers, meeting business goals, and fostering team collaboration. Key indicators include on-time delivery, stakeholder satisfaction, and the ability to adapt to change. Teams often use a combination of metrics like velocity, customer feedback, and business impact to assess performance. For example, a project that delivers a high-quality product on schedule and receives positive user feedback would be considered successful in an Agile context.

Agile-показатели и KPI — это лишь один из аспектов построения командной культуры. С их помощью можно получить количественное представление об эффективности команды и поставить перед ней цели, поддающиеся количественной оценке. Они важны, но не стоит на них зацикливаться. Прислушивайтесь к участникам команды во время ретроспектив, ведь ваше внимание тоже важно для создания доверительных отношений, повышения качества продукта и сокращения времени до выпуска. Изменения должны основываться как на количественных, так и на качественных показателях.