Привет! Представляю вашему вниманию перевод статьи «Why I Don’t Use Story Points for Sprint Planning» автора Mike Cohn.
Как описано в «Agile Estimating and Planning», я большой поклонник story points для оценки бэклога продукта. Тем не менее, я также рекомендую оценивать бэклог спринта в часах, а не в story points. Почему это кажущееся противоречие? Ранее я писал о причинах. Я рекомендую использовать разные единицы измерения (points и часы) для различных бэклогов.
Но мне часто задают связанный с этим вопрос, который я хочу задать здесь:
Мне любопытно, почему вы не используете story points для планирования спринта. Я думал, что смысл измерения скорости в story points был, частично, в том, чтобы определять, сколько мы можем взять (или зафиксировать) в спринт. Используете ли вы только story point для долгосрочного планирования (например, планирования релизов)?
Я не использую story points для планирования спринта, потому что story points это полезная долгосрочная мера. Но 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).
Об авторе: Mike Cohn является одним из авторов Scrum-методологии разработки программного обеспечения. Он один из основателей Agile Alliance и Scrum Alliance. Специализируется на помощи компаниям во внедрении и улучшении использования agile процессов и методов создания высокопроизводительных команд.
Список литературы: Agile Estimating and Planning, Mike Cohn, 2005 год.
P.S. А вы оцениваете бэклог спринта в часах или story points?
Автор: Андрей
