Хабрахабр

[Из песочницы] Почему я не использую story points для планирования спринта

Привет, Хабр! Представляю вашему вниманию перевод статьи «Why I Don’t Use Story Points for Sprint Planning» автора Mike Cohn.

Тем не менее, я также рекомендую оценивать бэклог спринта в часах, а не в story points. Как описано в «Agile Estimating and Planning», я большой поклонник story points для оценки бэклога продукта. Ранее я писал о причинах. Почему это кажущееся противоречие? Я рекомендую использовать разные единицы измерения (points и часы) для различных бэклогов.
Но мне часто задают связанный с этим вопрос, который я хочу задать здесь:

Я думал, что смысл измерения скорости в story points был, частично, в том, чтобы определять, сколько мы можем взять (или зафиксировать) в спринт. Мне любопытно, почему вы не используете story points для планирования спринта. Используете ли вы только story point для долгосрочного планирования (например, планирования релизов)?

Но points не полезны в краткосрочной перспективе. Я не использую story points для планирования спринта, потому что story points это полезная долгосрочная мера.

Это не работает. Было бы уместно, чтобы команда сказала: «У нас средняя скорость 20 story points, и у нас осталось 6 спринтов, поэтому мы закончим около 120 story points в этих шести спринтах».
Было бы неуместным, чтобы команда сказала: «У нас средняя скорость 20 story points, поэтому мы закончим в следующем спринте».

На текущий момент они сыграли 41 игру и забили в среднем 98 очков за игру. Предположим, что баскетбольная команда находится в середине своего сезона. Но они не должны говорить перед какой-либо конкретной игрой: «У нас в среднем 98, поэтому мы заберем 98 сегодня». Было бы уместно сказать: «Вероятно, мы будем забивать в среднем по 98 очков за игру в оставшейся части сезона». Вот почему я говорю, что скорость является полезным долгосрочным предсказателем, но не является полезным краткосрочным предсказателем.

Скорость будет изменяться от спринта к спринту.

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

Нет обсуждения скорости. Нет обсуждения story points. Речь идет только об обязательствах, и мы решаем, сколько мы можем выполнить, разбивая пункты бэклога продукта на задачи и оценивая их.

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

Я использую термин «capacity», чтобы ссылаться на это количество часов, потому что скорость зарезервирована для того, чтобы ссылаться на измерение объема запланированных или выполненных работ, как указано в единицах, используемых для оценки бэклога продукта (что я рекомендую делать с использованием story points). Также будет верно, что команда будет выполнять примерно одинаковое количество часов от одного спринта до следующего.

Он один из основателей Agile Alliance и Scrum Alliance. Об авторе: Mike Cohn является одним из авторов Scrum-методологии разработки программного обеспечения. Специализируется на помощи компаниям во внедрении и улучшении использования agile процессов и методов создания высокопроизводительных команд.

Список литературы: Agile Estimating and Planning, Mike Cohn, 2005 год.

S. P. А вы оцениваете бэклог спринта в часах или story points?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть