Метрики Scrum в условиях remote

Agile метрики нужны всегда: они помогают отслеживать прогресс, измерять продуктивность, контролировать качество планирования. Теперь, когда формат работы изменился на удаленный, Scrum практики тоже нужно адаптировать под тотальный remote.

Находясь в офисе, на качественные атрибуты продуктивности и здоровья команды смотрят иначе: не с метриками, как таковыми, а через процессы и способы взаимодействия. Scrum Master-ам известны количественные показатели Focus Factor и Adopted Work, но в условиях удаленной работы, приоритетнее качественный анализ, который поможет сохранять прозрачность и собирать факты, необходимые команде и стейкхолдерам для принятия правильных решений.

Цели сбора Agile-метрик

Метрики помогают составлять прогноз, планировать работу и отвечать за результат, основываясь на фактах, а не предположениях.

Чтобы решить, на какие показатели обращать внимание, Scrum Master-у важно понимать цели, для которых он собирает метрики. Целью может быть: показать продуктивность SM для руководства; понять, как мотивировать людей; увидеть причины прогресса и неудач команды.

Собранные данные нужны для того, чтобы:

1. Ответить на вопросы стейкхолдеров. Если стейкхолдеры получают исчерпывающие ответы на свои вопросы, то они дают качественную и количественную обратную связь, на основании которой можно принимать решения.
2. Обеспечить прозрачность, понимание происходящего. Прозрачность — это один из важных принципов, наряду с инспектированием и адаптацией. Определенные метрики помогают укрепить прозрачность и адаптировать текущие действия, чтобы с каждой следующей итерацией команда работала продуктивнее.
3. Помочь следить за работой (своей тоже). В изменившихся условиях, ключевой вопрос у многих Scrum Master в Agile сообществе — это как быть еще более продуктивным в своей роли; как не выпадать из связи и практик, которые с таким трудом настраивали в команде. Здесь важна саморефлексия Scrum Master, чтобы на основании данных понимать, насколько он сам остается эффективным и помогает это делать команде.

Главная задача отслеживания метрик — помочь команде выйти на максимальную продуктивность в контексте актуальной ситуации.

Daily Scrum и другие события

Scrum церемонии сами по себе не являются метриками, но то, насколько качественно происходят встречи, будет важным показателем здоровья команды.

Например, Sprint Retrospective отражает, как информация циркулирует между участниками процесса, насколько команда здорова, открыто и смело общается, и может «челленджить» Product Owner-а или наоборот.

Daily Scrum — тот момент, когда команда собирается для синхронизации, чтобы проинспектировать движение к цели спринта. Ежедневные 15 минут вместе с командой — это одна из базовых качественных характеристик, которая показывает:

• остается ли команда сфокусированной;
• знают ли люди, что они хотят сделать и для чего;
• уважает ли команда приоритеты, которые сама озвучила на планировании;
• существует ли прозрачность и доступность внутри команды — насколько знания понятны для остальных участников проекта, действительно ли информация свободно циркулирует между участниками.

На какие метрики обратить внимание SM

Важно собирать и отслеживать качественные метрики, чтобы не входить в «состояние плато», когда все вроде настроено, но никакого развития дальше не предвидится. Две самые распространенные метрики — это Burn Down Chart и Cumulative Flow Diagram.

Burn Down Chart

Пример Burn Down Chart

Burn Down Chart (диаграмма сгорания задач) наглядно показывает, сколько работы остается на каждый момент времени и сколько задач уже сделано. Диаграмма должна быть общедоступной и обновляться ежедневно, чтобы команда видела текущий прогресс.

Метрика очень простая, потому что в большинстве task tracker-ов график строится автоматически:

• вертикальная ось Y – сумма общих эстимейтов или количество задач;
• горизонтальная ось X — количество дней, которое прошло в конкретном спринте.

Например, на старте команда взяла 128 story point-ов. Затем что-то произошло: в первый день спринта эстимейты увеличились и все последующие дни команда закрывала задачи.

Возможно, Product Owner без обсуждения с командой с половины спринта захотел убрать часть задач и дополнить спринт другими. Если он это делает, это отразится на диаграмме.

В Jira можно соединить на одной визуализации оба графика в Sprint Report и увидеть:

• как уменьшалось количество запланированных вначале задач;
• количество часов, которое потратили на закрытие этих задач;
• скорость команды.

Cumulative flow diagram

Это визуализация статуса всех задач спринта с первого до последнего дня. Cumulative Flow Diagram показывает не только количество проделанной работы, но и сфокусированность команды на задачах.

Пример Cumulative Flow Diagram

Обычно на Cumulative Flow Diagram будет столько цветов, сколько статусов в вашем task tracker. Если статусы, как в примере: Non Started, Design, Coding, Testing, Complete — тогда будет 5 цветов.

Как работают обе метрики вместе

Например, в первый день спринта на Burn Down Chart было N story point (если оценка была в story point). Дальше ничего не происходило, и в последний день перед Sprint Review все story points переместились в «завершенное».

Cumulative Flow Diagram покажет, что происходило с задачами. Ситуации могут быть разные:

• Все задачи в первый день уже были в работе. Это говорит о том, что, возможно, они тянутся еще с прошлого спринта.
• Все задачи перешли в Testing. Например, вы предполагали, что задачи перейдут в Testing на 8 день вашего спринта. Задачи перешли, но ничего не происходит, они не возвращаются на доработку, а и дальше остаются в тестировании, а потом одним махом закрываются.
• В Cumulative flow diagram в первый день спринта 8 задач были Not Started. Дальше, какие-то задачи пошли в Design, какие-то в Coding. Что не так? В начале было 8 задач, к четвертому дню задач стало 10, а потом еще больше. Почему-то задачи добирали и добирали. Так не должно быть. И на графике это визуально видно.

Количественные метрики для принятия решений

Пример метрики Velocity

Разграничение между качественными и количественными метриками можно использовать для принятия решений и определения «узких мест» проекта.

Количественные метрики:

• Velocity — скорость, производительность команды. Количество задач и story point-ов, обработанных за один спринт. Velocity будет увеличиваться, когда команда учится работать быстрее и производительнее, совершенствует свои навыки. Если изменился формат — и люди теперь работают удаленно, то логично, что первые несколько спринтов Velocity упадет.
• Quality — метрика качества: сколько багов создается на релиз, модуль, или другую составную часть вашего продукта. То есть это метрика качества продукта, релиза, которую можно отслеживать количественно: сколько конкретно было багов.
• Story Creation — сколько историй создано вместе с командой. Story Creation — это не о тех историях, которые Product Owner или Scrum Master создали сами, а потом дали в команду для оценки. Должна быть совместная работа, а не «я все создал, а вы оценивайте».
• Accuracy of Commitment (Forecast). Насколько команда может придерживаться собственного плана, озвученного в первый день на Sprint Planning. Например, команда сделала прогноз, что закроет 24 пользовательских истории, чтобы прийти к цели спринта, а в итоге, закрыла всего 17.
• Overtime — овертаймит команда или нет, сколько времени это занимает, — это тоже метрика, которую можно посчитать.

На что смотреть обязательно

Кроме понимания «Зачем нужны эти конкретные данные?» и отлаженных процессов, для работы с метриками важен контекст. Например, если смотреть исключительно на скорость (Velocity), в отрыве от других данных, это не дает ничего, кроме статистики.

По одной отдельной метрике трудно говорить о том, насколько команда развивается, есть ли какие-то сложности, поэтому важно оценивать в комплексе.

Какую бы метрику не использовали, есть индикаторы, на которые смотреть обязательно:

• Отслеживайте Burn Down Chart не только по одному спринту, но смотрите шире: по командам, релизам и проектам.
• Замечайте количество и приоритетность дефектов: насколько их много в одном спринте или в одной истории.
• Смотрите на то, как улучшается или ухудшается Velocity и почему.
• Обращайте внимание на стабильность работы команды.
• Следите за скоростью backlog refinement: сколько спринтов нужно команде для детализации user story или любых других требований, с которыми они будут работать в следующих спринтах.
• Проверяйте стабильность работы Product Owner-а и команды с inflow vs outflow. Какие источники inflow, насколько стабильны требования, которые заходят в работу и насколько стабильно эти требования выполняются.

Вместо вывода

Плюс «удаленки» в том, что можно собрать больше данных, потому что получится уделить время индивидуально каждому участнику.

В первом спринте берите минимум метрик: выбирайте такие, которые помогут настроить дисциплину, научат следовать правилам и договариваться друг с другом.

Если команда опытная и работает слаженно, понадобится отслеживать меньше показателей. Есть много команд, которые не используют какую-то из представленных сегодня метрик. И это тоже нормально.

Задача не в том, чтобы собирать данные просто ради отслеживания. Успешный Scrum Master пользуется метриками так, чтобы помогать команде выходить на максимальную продуктивность в контексте актуальной ситуации. Особенно удаленной☺