Как часто команда Scrum должна выполнять свои обязательства по Sprint? [закрыто]

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

Я знаю, что в официальном Scrum Guide теперь используется слово «прогноз», а не обязательство, вероятно, для решения этих проблем.

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

Спасибо.

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы ответить на ваш конкретный вопрос, из трех организаций, где я использовал scrum, только одна отслеживала показатели "пропустить фиксацию" с течением времени. Для этой компании команды обычно достигают своего прогноза примерно в 85% случаев.

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

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

Что более важно, так это долгосрочная тенденция в вашей скорости. Если каждую неделю вы прибавляете к своей скорости 15 сюжетных очков, но делаете только на 10 больше, чем на прошлой неделе, разве это плохо? В некоторых местах они считают это «растянутыми целями».