Должна ли скорость влиять на приверженность команд в схватке

Question

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

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

Мне кажется Parkinson's law вот-вот налетит.

Не лучше ли держать число скоростей скрытым для команды и использовать его только для оценки того, когда будет выполнена определенная история/история?

Answer 1

Это хорошая идея сохранить скорость в виду при начале Спринта планирования, а не в конце.

Velocity - это руководство для команды разработчиков. Например, со скоростью 15, они рассмотрят вопрос об использовании этого общего количества Story Points в Sprint. Однако, как часть планирования Sprint, они разбивают эти истории на задачи. Только в этот момент они получают четкое представление о том, что они могут сделать в предстоящем спринте. Это может быть 10 Story Points, это может быть 20 Story Points. Velocity - всего лишь путеводитель.

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

Кроме того, последняя версия руководства Scrum Guide отбросила все ссылки на слово «обязательство». Теперь мы более точно используем слово «прогноз».

Надеюсь, что это поможет.

Answer 2

Это зависит от истории трека команды и их скорости в течение последних нескольких спринтов. Поэтому, если они некоторое время усредняли 7, то принятие 10-го рассказа - это попытка команды выйти из строя.

Небольшая коррекция, мы больше не используем термин «обязательство», поскольку оно неправильно интерпретируется руководством, а команды страдают «маршами смерти», если они не выполняют своих обязательств; хотя они достигли 95% цели спринта. Вместо этого мы используем прогноз , поскольку мы никогда не сможем гарантировать успех на основе неопределенности, сложности и неожиданных событий.

Попробуйте разбить историю на более мелкие истории, чтобы команда могла их достичь, однако поощряйте их лучше выполнять каждый спринт и нажимать немного сложнее каждый спринт. Таким образом, в ретроспективе, продолжайте спрашивать: «Что мы можем сделать, чтобы улучшить и сделать больше?» Будьте реалистами, что чувствует команда.

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

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

Answer 3

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

Answer 4

Скорость - хорошая мера, и может быть прогнозируемый через пролет Спринта, основанный на прошлых характеристиках/скорости. Спринт обычно позволяет использовать буфер в оценках скорости, чтобы можно было учитывать непредвиденные обстоятельства. Этот буфер основан на исторических данных, предстоящем ВОМ и т. Д.

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

В идеале, команда имеет скорость в виду во время Backlog Grooming - это позволяет команде Scrum извлекать истории из отставания, что они знают, что они, как ожидается, закончат вовремя. Планирование Sprint - это то, где производственная группа обсуждает нюансы этих рассказов пользователей, ухоженных/размерных, чтобы лучше понять функциональные требования.