Скорость не плато со временем, почему?

Я составил график сгорания моей команды и его скорость за итерацию. Для меня это выглядит очень плохо (скорость сильно колеблется). Что я должен искать, чтобы диагностировать причину этого поведения?

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

• Команда пытается скорректировать свои оценки историй, основываясь на их недавней скорости, вместо того, чтобы сохранять исторические точки постоянными и корректировать, сколько историй они берут.
• Вы не ломаете истории достаточно маленькими.
• Слишком много ваших историй находятся в более высокой степени детализации. Например, у вас есть много 20 указателей, которые вы не хотите менять на 13 или 40.
• У вас есть много «похмельных» историй, которые не совсем заканчиваются в одном спринте.

Вы неправильно используете скорость в качестве показателя производительности, как будто некоторое количество принятых баллов - это «хороший» спринт, а что-то меньшее, чем «плохой» спринт.

Скорость (которая является ужасно неправильно названной концепцией) должна использоваться в качестве перспективного инструмента для оценки того, сколько функций команда может использовать в следующем спринте, т.е. скорость должна использоваться для планирования мощности.

http://jimhighsmith.com/velocity-is-killing-agility/

Вот заметная цитата из статьи: «Проблема заключается в весе, придаваемом скорости и превращающем ее в показатель производительности».

Там может быть проблема в том, что похоже на значительные различия в вашей скорости. Это не означает, что команда делает что-то не так, но результат в том, что способность команды к будущим спринтам нельзя предсказать очень хорошо. К сожалению, это не тот вопрос, на который любой из нас может ответить для вас. Вы должны копаться в предмете с помощью ретроспективы. Что на самом деле происходит?

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

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

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

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

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

• Возможно, ваш член команды не является преданным членом команды. Чтобы работать и понимать друг друга, им нужно работать вместе достаточно долго. Если ваша команда часто меняет людей в команде на вход / выход, это делает ее динамичной и влияет на скорость.
• Карты истории слишком велики. Таким образом, команда не может вдаваться в подробности при планировании / оценке. Во время спринта они обнаружат, что что-то сложнее, чем они думают.
• Я думаю, что вы делаете разборки. В Scrum мы должны выполнить часть 1 планирования спринта (владелец продукта выбирает, что делать) и часть 2 планирования спринта (команда решает, сколько они могут сделать). Таким образом, ситуация может быть такой: после того, как владелец продукта выберет карты для спринта, команда не будет достаточно подробно разбираться в части 2 планирования спринта, поэтому они не смогут найти скрытую проблему, о которой им нужно сообщить владельцу продукта. Если они сначала обнаружат проблемы, они сломают их ИЛИ подумают, как избавиться от риска. Это делает оценку достаточно точной перед началом работы над спринтом.
• Если сюжет карты не детализирован, оценка не будет точной. Оценка вначале может быть грубой, но перед началом спринта или перед тем, как карты истории отправятся в спринт, их необходимо разделить и уточнить, чтобы получить почти правильную оценку. Это помогает скорости команды быть более стабильной.
• Владелец продукта может быть не в состоянии прояснить сюжетные карты достаточно ясно, прежде чем начать работу над спринтом. Это также очень важно, потому что это цель команды работать в течение этих двух недель. Если владелец продукта просто выбирает карту для спринта, а команда еще не понимает ее, им все равно нужно понять их во время спринта, и может получиться ответ, что у него больше, чем они обсуждали, и оценка неверна. Итак, это явно влияет на скорость.
• и т.д...

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

Ваша скорость имеет шум (колебания). Возможные причины:

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

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

Однако, если вы отфильтруете шум (скользящее среднее за 5 последовательных спринтов), то ваша скорость все равно будет снижаться после 20 спринтов. Это затрудняет планирование релизов, и это стоит изучить:

• Является ли «определение выполненного» слишком слабым, и команда накапливает оставшуюся работу от предыдущих спринтов?
• Становится ли организация лучше отвлекает внимание от разборок и навязывает команде невыполненную работу?
• Большие истории (эпопеи) внизу журнала были оценены более оптимистично, чем более подробные истории сверху?