Расчет скорости на основе количества пользовательских историй, завершенных за спринт

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

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

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

Как справиться с этим?

Завершено ли отслеживание клиента или команды на основе историй? Кроме того, если установлен крайний срок выпуска, является ли объем гибким? Или это каскадный проект с разбросанными по нему модными словечками?
Если все истории не имеют одинакового размера, отслеживание завершенных историй по своей сути не является полезными данными.
@Erik Scope также гибок; в том смысле, что они создают дополнительные пользовательские истории внутри спринта. Сроки выпуска определяются заранее, а разработка происходит поэтапно.

Ответы (2)

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

Существует довольно большое движение «без оценок», которое добивается большого успеха в правильном размере всех историй, чтобы они были примерно одинакового размера, а затем они учитывали только количество. Они не должны быть точно такими же. Чтобы дать конкретное (хотя и гипотетическое) правило, команда, использующая очки со средней скоростью 40, вероятно, захочет, чтобы большинство историй было около 3 с небольшим количеством из них на 1 или 5, прежде чем они смогут отбросить очки. (Это глубоко ошибочный пример, на самом деле не используйте его для реализации, просто попытайтесь дать что-то конкретное.

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

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

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

Это не было правдой в моем опыте. Я видел, как многие команды преуспели в подсчете историй, а не в баллах. Фактически, все движение без оценок основано на таких успехах. Это может или не может быть сделано хорошо в этом случае, но это, безусловно, возможно.
Имея 19 историй по 1 баллу и одну историю по 20 баллов, метрика, которая говорит «половина историй завершена», ровно ничего не говорит о способности завершить другую половину за то же время. Так что да, любой проект может быть успешным с любой метрикой. Я был в проекте, где PM просто лгал и составлял красочные диаграммы, чтобы заставить клиентов платить, независимо от цифр. Но если вы хотите предоставить цифры, которые математически обоснованы для прогнозов, количество историй так же ценно, как интуиция. У некоторых людей отличное чутье. Это не значит, что это отличный метод.
Миллион голосов за это — это сломанная метрика и не имеет никакой ценности.
@Daniel: В движении без оценок все должно быть уточнено, пока все не станет примерно одинакового размера. Когда вы дойдете до этого момента, вы можете с таким же успехом сказать, что каждая история — это 1 SP. Ошибка слепого подсчета историй (без уверенности, что они одинакового размера) заключается в том, что вы считаете, сколько яблок и дынь помещается в одну корзину.
Расчет скорости на основе количества пользовательских историй, завершенных за спринт
СпросиСетьПолитика конфиденциальности1y, 0v