Как оценить скорость спринта с разной вместимостью команды?

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

Это может быть простой подход, но почему бы вам не рассчитать свою скорость как completed story points * capacityили completed story points / capacity, в зависимости от того, как измерить емкость. Если вы измеряете емкость в человеко-часах, используйте второе. Если вы измеряете емкость в процентах от 40-часовой недели, используйте первое. Когда вы начнете снимать сюжетные очки, у вас должно быть хорошее представление о вашей способности к заданному спринту и использовать исторические данные вашего проекта для определения сюжетных баллов, завершенных для данной нагрузки.

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

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

Скорость может варьироваться, даже если емкость остается неизменной.

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

Скорость это руководство, а не мера. Просто возьмите среднее значение всех ваших спринтов (с учетом стандартного отклонения) и среднее значение ваших худших трех, среднее значение ваших лучших трех и скажите: «Мы определенно сделаем это, мы можем это сделать, мы не получим это сделано ". Проведя три линии в вашем (полностью оцененном) бэклоге, используя эти три скорости и приблизительный срок (представьте, что это 12 спринтов и 12х ваша худшая скорость 75, 12x ваша лучшая 120 и 12x ваша средняя 90. В отставании 100 баллов даже в худшем случае вы могли бы сделать три четверти, в лучшем случае вы бы все это пригвоздили и в среднем вы бы доставили большую часть).

С этими данными ваше ПО может принимать все решения, которые ему необходимы, в том, что он ДОЛЖЕН иметь, мы хотели бы иметь и то, что он не против оставить.

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