Обновление очков пользовательской истории после завершения Истории пользователей

Question

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

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

Во время планирования команды используют шкалу точек пользовательской шкалы (Фибоначчи или подобное) для измерения количества усилий для каждой Истории пользователей. Общие методы оценки включают в себя полномочия 2 (1, 2, 4, 8), последовательность Фибоначчи (1, 2, 3, 5, 8 и т. Д.) Или аналогичные.

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

Я читал и просмотр на некоторое время, пытаясь ответить на вопрос без особого успеха:

После завершения пользователя Истории количество реальной работы требуется отличается от первоначальной оценки. Так как неопределенность ушла сейчас, следует ли объем фактической работы отражать значение в шкале User Story Point? Или, с другой стороны, есть ли свобода использовать более точные значения? теперь, когда разработчик точно знает, сколько усилий он потребовал для завершения Истории пользователей.

Мое рассуждение заключается в том, что, отслеживая фактическую работу с более точными значениями, чем те, которые предоставляются шкалой (Фибоначчи или другие), команда получит более точную метрику, которая позже повлияет на их скорость в середине/долгосрочный.

Answer 1

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

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

Теперь рассмотрим следующий пример.

Команда отличается историей, которая кажется очень похожей на десятки подобных историй, которые они делали в прошлом. Они дают ему 3 балла. Но когда они делают разработку, которую они обнаруживают, возникает неожиданная проблема, которая приводит к гораздо большему количеству времени и усилий, чем они ожидали. После того, как работа будет выполнена, они изменят историю до 8 очков.

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

В следующем спринте аналогичная история происходит снова. Какое количество эталонных очков они должны дать? 1 или 8?

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

Answer 2

Оценки истории пользователя не могут быть изменены в рамках спринта.

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

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

Все это находится в проверке & адаптация также для оценок. После 3-5 спринтов команда будет более точной в своих оценках & также улучшит их скорость.