По мере того как пользовательские истории заполняются во всем спринте, количество фактической требуемой работы можно отследить как показатель. В некоторых случаях объем фактической работы будет либо больше, либо меньше, чем исходная оценка сюжетной точки пользователя.Обновление очков пользовательской истории после завершения Истории пользователей
В этих случаях разработчику потребуется ввести число, которое находится выше или ниже исходной оценки.
Во время планирования команды используют шкалу точек пользовательской шкалы (Фибоначчи или подобное) для измерения количества усилий для каждой Истории пользователей. Общие методы оценки включают в себя полномочия 2 (1, 2, 4, 8), последовательность Фибоначчи (1, 2, 3, 5, 8 и т. Д.) Или аналогичные.
Целью этих шкал является отражение уровня неопределенности, связанного с оценкой того, сколько усилий будет предпринята задача, поскольку задачи становятся больше. Например, для небольшой задачи, например, для чтения электронной почты, вы можете получить очень точную оценку того, сколько времени вам потребуется, чтобы прочитать ее; уровень неопределенности мал. Но по мере увеличения размера задачи, т. Е. Ответа на 50 разных электронных писем, сложнее узнать, сколько усилий потребуется; уровень неопределенности ваших оценок будет расти экспоненциально.
Я читал и просмотр на некоторое время, пытаясь ответить на вопрос без особого успеха:
После завершения пользователя Истории количество реальной работы требуется отличается от первоначальной оценки. Так как неопределенность ушла сейчас, следует ли объем фактической работы отражать значение в шкале User Story Point? Или, с другой стороны, есть ли свобода использовать более точные значения? теперь, когда разработчик точно знает, сколько усилий он потребовал для завершения Истории пользователей.
Мое рассуждение заключается в том, что, отслеживая фактическую работу с более точными значениями, чем те, которые предоставляются шкалой (Фибоначчи или другие), команда получит более точную метрику, которая позже повлияет на их скорость в середине/долгосрочный.
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что речь идет не о программировании. Управление проектами вне темы на SO. – BDL