Скорость спринта: как рассчитать и использовать скорость в Agile

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

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

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

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

• Что такое скорость спринта?
• Как измерить скорость спринта? 
• Зачем команды измеряют скорость спринта?
• Как улучшить скорость спринта?
• Часто возникающие недопонимания о скорости
• В чем разница между скоростью и вместимостью?

👻 Псс! Если вы новичок в Agile или вам нужно освежить память по конкретным терминам, откройте этот удобный Agile глоссарий в другой вкладке и обращайтесь к нему при необходимости.

Что такое скорость спринта?

Скорость спринта (Sprint Velocity) - это количество сторипойнтов, завершенных командой за один спринт. Некоторые команды используют различные единицы измерения, такие как часы или количество завершенных историй, для расчета своей скорости. Но независимо от используемых данных, концепция остается прежней: скорость показывает, сколько работы команда выполнила за один спринт.

Как измерить скорость спринта?

Команды рассчитывают скорость в конце каждого спринта. Просто сложите количество сторипойнтов, выполненных во время спринта. Вашей метрикой скорости будет абсолютное количество очков истории, выполненных вашей командой.

Например:

Предположим, что вы оценили историю A в 4 сторипойнта, историю B в 2 сторипойнта, и историю C в 3 сторипойнта, и все три были завершены. Ваша скорость будет равна 9. Но если вы завершили только половину истории A, вы не можете учесть никакие сторипойнты от нее, и ваша скорость для этого спринта будет равна 5. В Scrum требуется, чтобы задачи помещались в один спринт. Исключение незавершенных сторипойнтов из скорости побуждает команды делать задачи более мелкими в будущем.

Скорость измеряется на уровне команды, а не для отдельных участников. Это связано с тем, что оптимизация работы команды превосходит преимущества оптимизации работы отдельных участников. Хоть это и не указано явно в Scrum гайде или Agile манифесте, это предполагаемый принцип для обоих подходов.

Зачем команды измеряют скорость спринта?

Скорость (velocity) может помочь командам более точно планировать свои спринты. Это связано с тем, что это помогает командам понять, сколько очков истории они обычно могут выполнить за один спринт. Это число также может послужить началом разговора, когда вы готовите почву для ваших ретроспектив.

Скорость помогает планировать ваши спринты

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

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

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

Скорость позволяет визуализировать прогресс

Многие команды используют скорость спринта в виде нисходящей линии на диаграмме сгорания (Burndown chart). Диаграммы сгорания помогают командам получить более ясное представление о том, как выглядит процесс выкатки задач в течение спринта. Уменьшается ли количество сторипойнтов плавно в течение спринта или часто происходит спешка к концу?

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

Скорость дает более четкую направленность

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

Например, ведущий ретроспективы может сказать:

"В этом спринте мы закрыли задач на 21 сторипойнт.  Наша средняя скорость за последние три спринта составляет 25 сторипойнтов. Это означает, что наша скорость немного снизилась в этом спринте по сравнению с предыдущим".

Если ваша скорость сильно колеблется между спринтами, это может указывать на то, что ваши пользовательские истории (user stories) слишком большие. В этом случае вам может потребоваться разделение историй на более мелкие части. Но это также может указывать на какие-либо блокеры в задачах, или другие проблемы в процессе, которые требуют диагностики во время ретроспектив.

Предположим, что количество ошибок в работе вашей команды начало увеличиваться в последнее время. Это может указывать на то, что команда работает слишком быстро, завершая много задач без достаточного тестирования. В этом случае вы можете стремиться к более низкой скорости (да, замедляться!).

Ожидаемым результатом замедления скорости является уменьшение дефектов в последующих спринтах, потому что команда уделяет больше времени на код ревью, пишет больше тестов. Более низкая скорость в этом случае может привести к более здоровому показателю Escaped Defect Rate - еще одной популярной метрике Agile.

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

Как улучшить скорость спринта?

Вы можете улучшить скорость спринта следующим образом:

• 🎓 Лучше прорабатывать бэклог. В хорошо разработанном бэклоге содержится много деталей. Когда наступает время начать новую задачу, участники команды имеют всю необходимую информацию для ее выполнения. Проработка бэклога часто включает назначение оценок в виде сторипойнтов, которые указывают на объем усилий, требуемых для выполнения задачи. Проработка бэклога помогает командам поддерживать высокую скорость спринта и фокусироваться на выполнении задач, так как все обсуждения и планирования проведены заранее.
• 🤖 Автоматизация частей рабочего процесса. Изучите возможности автоматизации повторяющихся задач, таких как автоматизированное тестирование, автоматическое генерирование кода или использование шаблонов для определенных частей продукта. Это может потребовать начальных затрат для настройки, но оно окупится в виде повышенной скорости выполнения задач.
• 👨🏻‍💻 Быть в курсе изменений или недостатков в команде. Хотя скорость измеряется на уровне команды, производительность отдельных участников естественным образом влияет на эту метрику. Возможно, требования изменились, и в команде не хватает ключевых навыков, или бывший лучший исполнитель переживает сложный период в жизни, что сказывается на скорости команды. При поиске способов оптимизации скорости следует учитывать эту возможность.
• 🔍 Анализ внешних зависимостей и технических проблем. Если внутри команды нет места для улучшений, следует обратить внимание на внешние факторы, которые влияют на скорость выполнения задач. Возможно, заказчик не предоставляет обратную связь вовремя, или другой отдел, например, финансовый, имеет сложный процесс утверждения покупок, необходимых команде. Также следует рассмотреть потенциальные технические проблемы, такие как старый тестовый сервер, который вызывает проблемы и снижает скорость выполнения задач.
• 🚀 Посвятите ретроспективу оптимизации скорости. Проведите ретроспективу с командой, когда вы хотите найти дополнительные возможности для оптимизации. Мартен Дальмейн предлагает список полезных вопросов, которые можно задать во время такой сессии, например: "Было ли много изменений в требованиях у задач?" или "Команда действительно составила план по достижению цели спринта?".

В начальных спринтах, скорость команды, практически наверняка будет сильно колебаться. Вы все еще калибруете оценки, созвоны занимают больше времени, и разработчики могут быть незнакомы с кодовой базой, поэтому времени на выполнение задач остается меньше, так как команда всё еще разбирается в процессах.

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

Мартен Дальмейн, руководитель продукта в Rodeo и представитель Serious Scrum, рекомендует заранее информировать всех об этой начальной переменчивости. Управление ожиданиями помогает стейкхолдерам сохранить веру в Scrum. Это также защищает мотивацию вашей команды.

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

Распространенные заблуждения о скорости

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

Скорость выполнения задач может помочь или навредить вашей команде в зависимости от того, как и кем она применяется. Ниже мы ответим на четыре вопроса о скорости выполнения задач в рамках спринта, чтобы прояснить общие недоразумения и злоупотребления.

Должны ли внешние стейкхолдеры использовать скорость выполнения задач для прогнозирования?

Иногда владельцы продукта (Product Owners, PO) используют скорость выполнения задач для прогнозирования выполнения спринта, функционала или проекта перед стейкхолдерами. Предположим, что общее количество сторипойнтов для вашего проекта составляет 100, а ваша средняя скорость выполнения задач в рамках спринта составляет 10. Тогда вы можете прогнозировать, что вам потребуется 10 спринтов для завершения проекта.

В этом случае есть две проблемы при использовании скорости выполнения задач:

• 😬 Она сопряжена с большой степенью неопределенности, и вам придется добавить большой запас к вашей оценке. Во время 10 спринтов многое может измениться, что повлияет на скорость выполнения задач. Члены команды могут уходить, могут прилетать срочные задачи, оценки могут оказаться неточными и так далее.
• 🎯 Она превращает число во внешнюю цель, а не в инструмент для команды. Редко когда внешние стейкхолдеры примут что-то в качестве оценки, которая может измениться. Как только оценка была дана, она часто превращается в жесткий срок. Это превращает скорость выполнения задач из метрики, принадлежащей команде, в фиксированный, внешне установленный крайний срок, который может добавить значительное давление на команду или привести к некоторым видам наказания в случае невыполнения.

Обратите внимание на разницу между этим способом использования скорости выполнения задач и тем, о чем мы ранее говорили, о ее использовании командой для определения ограничения во время планирования спринта. Прогнозирование, как в этом примере, служит только внешним стейкхолдерам, в то время как использование скорости выполнения задач в качестве ограничения или предела того, что может быть достигнуто, помогает команде более точно планировать свои спринты.

Следует ли отслеживать и сравнивать производительность команды с помощью скорости выполнения задач?

Скорость выполнения задач является ненадежной метрикой для отслеживания производительности команды. Использование этого числа также противоречит фундаментальным принципам Agile, таким как доставка ценности клиенту и доверие к командам, чтобы они самостоятельно организовывались и выполняли работу.

Скорость выполнения задач плохо подходит в качестве метрики производительности и превращается в "театр измерений" по нескольким причинам:

• ⚖️ Сторипойнты являются относительными единицами измерения. Сторипойнты являются "локальной валютой", уникальной для вашей команды. Один SP представляет разное значение для команды A и команды B. Сравнение между командами не работает.
• 👑 Команда контролирует число. Даже когда внешние лица берут контроль над скоростью выполнения задач, команда имеет окончательное право на это число. Они могут, например, завышать свои оценки во время планирования спринта, экономить на качестве работы или брать на себя только простые задачи, которые они могут быстро завершить, чтобы удовлетворить "цели скорости выполнения задач".

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

Мартен Дальмейн лаконично подводит итог в одной из своих статей: "Компании, которые одержимы скоростью выполнения задач, ничего не понимают в Scrum".

Должна ли скорость выполнения задач всегда увеличиваться?

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

Сооснователь Scrum Джефф Сазерленд довольно ясно высказывается по этому поводу в своей книге "Scrum: Искусство выполнения работы в два раза быстрее за половину времени":

"Как только у вас есть скорость выполнения задач, вы можете определить самое важное в Scrum: что мешает вам двигаться быстрее? Что вам мешает ускоряться?"

Если это не ясно, то на его веб-сайте указано:

"Скорость выполнения задач хорошо функционирующей команды Scrum должна постоянно расти примерно на 10% каждый спринт."

Однако многие практики Agile, такие как Мартен Дальмейн, эксперты, которых мы опросили, и Джон Катлер, который ввел термин "фабрика функций", не разделяют эту точку зрения. Они утверждают, что одержимость скоростью выполнения задач может привести к работе низкого качества, созданию функций продукта, не имеющих особой ценности для клиента, или выгоранию членов команды.

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

Итак, вернемся к нашему вопросу: должна ли скорость спринта продолжать расти? Мы бы сказали: «часто, но, конечно, не всегда и только по правильным причинам».

В чем разница между скоростью выполнения задач (velocity) и объемом работы (capacity)?

Скорость выполнения задач и объем работы - это две метрики подхода Agile, которые часто путаются. Обе они используются для измерения и прогнозирования того, сколько работы команда может выполнить, но делают это по-разному.

• 🏎️ Скорость выполнения задач (velocity) основывается на прошлых показателях производительности, чтобы прогнозировать правильный объем работы на следующий спринт. Например, сравнивая количество выполненных сторипойнтов за предыдущие спринты.
• 🏟️ Объем работы (capacity) фокусируется на ресурсах. Он берет значение скорости выполнения задач и корректирует его, чтобы оценить доступные ресурсы команды на предстоящие спринты.

Например, у вас есть команда из двух разработчиков, средняя скорость выполнения задач которой составляет 10 SP. Один из разработчиков будет в отпуске весь следующий спринт. В этом случае у вас будет на 50% меньше разработчиков, и ваш объем работ на следующий спринт составит 5 SP.

Когда отказаться от использования скорости выполнения задач

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

Allie Dyer Bluemel из Shortcut предлагает полезную оценку метрик, таких как скорость выполнения задач:

"Если их использование доставляет неприятности, если заполнение их является рутинной задачей, то измените способ их использования."

Когда дело доходит до скорости выполнения задач, вы и ваша команда находитесь в кабине пилота. Ваше внимание сосредоточено на цели спринта. Вы проверяете показатель скорости выполнения задач по мере необходимости. Владелец продукта (PO) в роли диспетчера держит вас в курсе вашего конечного пункта назначения.

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