Как менеджеры продукта могут оценить business value*, используя техники Agile
Перевод статьи из блога All About Product Management.
Ссылка на статью:
http://allaboutproductmanagement.blogspot.com/2008/02/how-product-managers-can-estimate.html
——перевод——↓
Недавно мы закончили scrum спринт. В рамках обзора (review) этого спринта команда разработчиков провела демонстрацию владельцам бизнеса новой функциональности и исправленных багов. На ретроспективе спринта и последующей дискуссии было замечено, что на демонстрации было отведено равное время для каждой из user story. Однако в некоторых user story были подправлены небольшие баги, в то время как реализация других user story привела к значительному улучшению главной страницы сайта. Вопрос заключается в том, как команда разработчиков может узнать, как много времени тратить на демонстрацию той или иной user story?
Один из способов – демонстрировать user story в порядке приоритетов. Однако это даст лишь порядок демонстрации и не даст никакого указания на то, сколько времени необходимо тратить на демонстрацию. Я думаю, что один из способов – представить оценку business value для каждой user story (см. Measuring business value with metrics). Команда разработчиков достаточно давно использует числа Фибоначчи (1, 2, 3, 5, 8, 13, 21, …) для оценки сложности user story и владелец продукта (product owner) и стейкхолдеры привыкли наблюдать, как разработчики используют poker cards для голосования по поводу сложности реализации пунктов из бэклога, а потом участники, которые дали самую маленькую и самую большую оценку, объясняют, почему они проголосовали именно так. Потом участники команды голосуют еще раз, основываясь на новой информации.
Шагом вперед будет использование такой же процедуры для стейкхолдеров. Business value будет зависеть от типа продукта, который вы разрабатываете. Для сайта сообщества это может быть: SEO; улучшение юзабилити; спонсорство, приносящее реальных доход; улучшение админской части, которое повышает эффективность работы; автоматизация процессов администрирования…
Когда бизнес-Фибоначи будут применяться, тем, кто проводит демонстрацию новой функциональности и исправленных багов, будет легко определить, сколько потратить времени на демонстрацию той или иной user story, таким образом обеспечивается релевантность обзора (review) и заинтересованность стейкхолдеров.
Однако существует и гораздо более значительная причина для использования busineess value для каждого из элементов бэклога: это не только помогает с определением приоритетов, но также может помочь с определением ROI каждого спринта и определять business velocity** тем же образом, как Scrum Master определяет technical velocity для команды или для отдельного человека. Оценка business velocity (см. Understanding your Velocity) будет также давать менеджеру продукта или владельцу продукта высокоуровневый индикатор того, какое количество business value команда может сделать в каждом roadmap.
* business value – ценность для бизнеса
** business velocity – скорость, с которой решаются задачи бизнеса
