Итак, у нас есть классная идея для нового продукта, мы знаем наших будущих пользователей и их потребности, которые закроет наш продукт. Прежде чем Scrum-команда приступит к работе в первом спринте, нужно создать бэклог продукта. Бэклог — это полный список всех требований (пользовательских историй) к продукту. Чем качественнее он подготовлен, тем эффективнее будет работа команды в спринте.
Сложность в том, что в самом начале пути Scrum-команде часто не хватает понимания о том, как должен будет выглядеть продукт, и что, собственно, предстоит сделать. С этого и следует начинать подготовку к наполнению бэклога.
Дорожная карта продукта
В случае продуктов, хорошо известных пользователям, и больших компаний наполнять элементами бэклог продукта будет проще, если предварительно сформировать видение и высокоуровневый план развития продукта — дорожную карту (Product Roadmap).
Это необязательный этап: стартапы и инновационные продукты, у которых нет аналога на рынке, на начальном этапе в дорожной карте не нуждаются — в этих случаях стоит начать с пользовательских историй (User Story).
При разработке дорожной карты главное не закапываться в детали функционала и больше внимания уделить видению целей и функций продукта. Эти функции затем лягут в основу элементов бэклога.
За бэклог отвечает владелец продукта, но не обязательно только он: команда и другие заинтересованные стороны (стейкхолдеры) также могут участвовать. Обдумывая каждую идею к функциональности нашего продукта, важно собрать по нему все доступные отзывы от заинтересованных людей внутри компании и от клиентов.
Работа по Scrum не отрицает постановку долгосрочных целей, однако при наполнении бэклога наиболее подробно следует проработать элементы, которые войдут в первые 1-2 спринта. Элементы для последующих спринтов можно описывать с меньшей степенью детализации — скорее всего, они потребуют доработки с учетом обратной связи.
Не только пользовательские истории
Пользовательские истории (User Story), или описания потребностей клиента, которые он может закрыть с помощью нашего продукта, и пользы, которую получит в результате его использования, — основная часть бэклога. Однако не единственная: при наполнении бэклога важно также уделить внимание техническим работам.
При создании пользовательских историй следует учитывать разные группы пользователей. История обычно строится по принципу «действие и причина»:
как ____, я хочу ____, чтобы ____.
При всей важности бэклога в начале работы над продуктом не стоит слишком затягивать сроки создания бэклога — важнее начать действовать и получить первую обратную связь. Затем, узнав больше о продукте, пользователях и проанализировав обратную связь, бэклог можно будет актуализировать.
Приоритизация
Итак, бэклог наполнен элементами. Теперь пришло время разобраться, сколько усилий потребует выполнение каждого из них (провести оценку трудоемкости) и какие элементы следует взять в работу в первую очередь. Это непростая аналитическая задача, решение которой облегчают инструменты вроде WSJF — об этой методике мы подробно рассказывали в материале «Модель приоритизации бэклога WSJF».
Скорее всего, в течение спринта поступят новые задачи. Важно поместить их на правильную позицию в бэклоге. Некоторые задачи могут оказаться действительно нуждающимися в срочном выполнении, большинство же после обсуждения с заказчиком уйдут на следующие спринты.
Критерии готовности
Прежде чем приступать к работе, важно определить, как команда в процессе работы поймет, что элемент бэклога полностью реализован. Для этого разрабатываются стандартизированные критерии готовности (Definition of Done, DoD), которые гарантируют, что вся команда понимает, какой результат ожидается от выполняемой ими работы.
