Какой лучший способ оценить сюжетные моменты в схватке?

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

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

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

Я не думаю, что это большая проблема.

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

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

Если скорость меняется слишком быстро для комфорта, тогда один ответ - канонические истории. Пройдите последние пару месяцев, выбрав по 3 истории, чтобы представить уровни баллов, которые вы используете. Положите их на стену, где вы делаете оценки. Затем, как вы оцениваете, используйте их для сравнения с историей, с которой вы имеете дело. Это должно уменьшить как дрейф, так и волатильность в ваших оценках.

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

Дефляция в основных точках может быть легкой проблемой, так как, когда ваш диапазон оценок точек сжимается, вы начинаете терять информацию о тонкой настройке скорости, и это сжатие может иметь негативные последствия при оценке длины для доставки более долгосрочного выпуска. планирование (поскольку вы собираетесь умножать ошибки, вносимые сжатием всех ваших историй в узкий диапазон). В целом, вы хотите, чтобы результаты увеличения скорости благодаря опыту были выражены в том, что они взяли на себя больше историй, а не понизили оценки. Способ борьбы с этим состоит в том, чтобы постоянно ссылаться на предыдущие завершенные оценки и всегда следить за сложностью. Никогда не говорите, сколько времени вы думаете, что-то займет, просто сравните общую сложность истории по сравнению с предыдущими историями. Позволять' скажем, у вас есть приложение, которое поддерживает мобильные платформы, и вы должны портировать на другое. Это похоже на предыдущий порт? Сложнее, потому что у платформы хуже оснастка? Проще, потому что у вас есть лучший отладчик? Это должно отражать ваши оценки, а не тот факт, что этот порт, скорее всего, будет работать быстрее, потому что ваши команды хорошо разбираются в оценках. Концентрация на сложности должна помочь решить эту проблему, если она есть.