User Stories — это один из наиболее популярных методов описания задач в беклоге. Популярная техника создания высокоуровневых требований. Но так как во время разработки беклога мы так же работаем с функционалом, “Фичами”, и задачами которые описывают каждый элемент который должен присутствовать в конечном продукте. И не зависимо от того важен этот функционал или нет — он будет описан и добавлен в беклог. Бек лог продукта — это “Живой артефакт” который растет изменяется и приоритезируется. И проблемы тут могут начаться когда беклог продукта начинает расти и становится на столько большим что владелец продукта не в состоянии целиком его охватить. Это проблема с определением важности и приоритетов задач.
Взглянем на стандартный беклог среднего размера. В моем случае он включает в себя примерно:
Разберемся что из себя представляют эти 25%. Что то добавленное в беклог в спешке, некоторые идеи или что то исходящее не от владельца продукта или клиента, что то замеченное во время демо. При беклоге в 100 задач — это не проблема, но как только беклог продукта начинает расти некоторые действительно важные элементы могут быть потеряны.
Большой беклог это не только отличный способ потерять важные задачи но еще и тормоз для команды, тормоз для развития продукта и мешает Agile работать корректно. Для структуризации беклога продукта можно использовать FDD подход, а именно “Функции”. Функции могут быть очень хорошим аналогом для задач в беклоге продукта либо Эпиком для User Stories которые не должны быть сейчас подробно описаны. Они позволят сократить белог продукта и помогут Владельцу Продукта охватить весь беклог и решить если что то должно быть переприоритезированно.
Формат фичи это простое описание:
Это отлична помощь для беклога продукта и это действительно работает для сокращения, мониторинга и работы с большими беклогами. Помогает не упустить что то действительно важное для пользователя. Так что если Вы стали замечать себя, тонущим в огромном количестве задач беклога — попробуйте использовать “Функции” и они вернут Вас в строй.
Взглянем на стандартный беклог среднего размера. В моем случае он включает в себя примерно:
- 60% описанных User Stories,
- 15% технических задач, доработок и багов
- 25% плохо описаных задач и функций которые владелец продукта хочет добавить в конечный продукт.
Разберемся что из себя представляют эти 25%. Что то добавленное в беклог в спешке, некоторые идеи или что то исходящее не от владельца продукта или клиента, что то замеченное во время демо. При беклоге в 100 задач — это не проблема, но как только беклог продукта начинает расти некоторые действительно важные элементы могут быть потеряны.
Большой беклог это не только отличный способ потерять важные задачи но еще и тормоз для команды, тормоз для развития продукта и мешает Agile работать корректно. Для структуризации беклога продукта можно использовать FDD подход, а именно “Функции”. Функции могут быть очень хорошим аналогом для задач в беклоге продукта либо Эпиком для User Stories которые не должны быть сейчас подробно описаны. Они позволят сократить белог продукта и помогут Владельцу Продукта охватить весь беклог и решить если что то должно быть переприоритезированно.
Формат фичи это простое описание:
- Возможность произведения оплаты
- Изменение цвета кнопки по ховеру
- Скрытие хеадера при скролле
Это отлична помощь для беклога продукта и это действительно работает для сокращения, мониторинга и работы с большими беклогами. Помогает не упустить что то действительно важное для пользователя. Так что если Вы стали замечать себя, тонущим в огромном количестве задач беклога — попробуйте использовать “Функции” и они вернут Вас в строй.
Поделиться с друзьями
Комментарии (3)
lum_member
22.11.2016 12:37Доброго! речь идет об объединении взаимосвязанных карточек, объединенных одной функцией? за счет этого сокращение беклога?
Coffeeguess
22.11.2016 12:40Добрый день. Совершенно верно. Все что может быть помещено в описание одной функции но требует большее количество задач для подробного рассмотрения.
Caelwyn
Я чего-то не понял, причём тут вообще дисковод для дискет?