Бэклог команды что это
Для чего и как проводят backlog grooming в продуктовых командах?
Бэклог продуктовых задач является одним из основных и обязательных артефактов Agile. Фактически, это набор требований, полученных от бизнеса и сформулированных в виде задач для разработки. Что нужно делать для того, чтобы эти задачи всегда были в порядке? И как это связано с концепцией backlog grooming?
Набор таких задач не несет ценности, если не приносит системной или структурной оптимизации. Очень важно правильно уметь управлять очередью задач, чтобы получить актуальный материал для работы. Как раз это и является целью такого процесса или активности, как backlog grooming.
Еще один тип встреч в Scrum
Backlog grooming — это собрание представителей Scrum-команды, во время которого обсуждаются детали бэклога продукта и готовится очередное планирование спринта.
Наверняка, большинство менеджеров и собственников продуктов благодаря опыту и практике знают, как превратить рутинное управление бэклогом в приятный процесс. Чтобы достичь этого, необходимо тщательно ухаживать за бэклогом, “чистить” и оптимизировать его. Это то, что называется grooming или product backlog refinement.
Согласитесь, любой продукт, как и человек, требует внимания и заботы.
Стратегический смысл груминга в управлении продуктом
Поскольку бэклог представляет собой очередь из пользовательских историй, то, часто, такой список может быстро стать перегруженным. Многие не знают, как справляться с такой перегрузкой, а бэклог продолжает расти.
Когда это случается, члены команды могут потерять фокус на важных задачах, а статус пользовательских историй может утратить ясность. Также могут возникнуть проблемы с оценкой времени и ресурсов.
Уход за бэклогом — это активность с участием менеджера проекта (менеджера продукта/ собственника продукта) и представителя клиента, направленная на то, чтобы разбить бэклог на истории пользователей, переориентировать их и задать новые приоритеты. Backlog grooming в управлении продуктом должен стать постоянным событием, основанном на глубоком анализе и четких действиях.
Этот процесс необходим для того, чтобы задачи, представленные в бэклоге, были актуальными, а те, которые представлены в верхней части списка, были готовы к планированию в спринте, реализации и релизу.
Груминг бэклога часто называют предварительным планированием. Обычно собственник продукта и представители команды организуют его в середине спринта.
Процесс не считается формальный частью Scrum. Тем не менее, рекомендуется, чтобы владелец продукта и представители команды выделяли до 15% каждого спринта для такой активности.
Главные цели процесса backlog grooming
Иногда собрание по backlog grooming называют story time session. В любом случае, цель этого мероприятия — обсудить текущий бэклог, определить и предложить действия по его оптимизации. Это может включать следующее:
Результат хорошего груминга
Результатам grooming является здоровый вид бэклога:
Какие инструменты использовать для backlog grooming?
Поскольку определение приоритетов — ключевой момент во время проведения backlog grooming, то очень важно грамотно визуализировать важность и взаимосвязь задач для дальнейшей работы с ними. Для упорядочивания идей и задач менеджеры продуктов используют параметры Value и Efforts. Сравнение этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные задачи.
В качестве заключения
Важно помнить, что grooming должен стать постоянным событием в управлении продуктом, которым не стоит пренебрегать. Этот процесс — это норма для качественного развития продукта. Самое главное в нем — оптимизировать задачи бэклога для последующей работы с ними.
Backlog grooming помогает прояснять релевантность задач, представленных в бэклоге, анализировать существующие вопросы и получать дополнительную информацию о задачах, которые пока не до конца ясны.
Подытоживая, отметим основные преимущества backlog grooming:
Бэклог Продукта (Product Backlog)
Бэклог Продукта – это упорядоченный и постоянно обновляемый список всего, что планируется сделать для
создания и улучшения продукта. Этот артефакт Скрама является единственным источником работы для Скрам-команды. Владелец Продукта несет ответственность за Бэклог Продукта, включая его содержимое, доступность и упорядочение.
Элементы Бэклога Продукта, которые могут быть доведены Скрам-командой до состояния готовности в течение одного Спринта, считаются готовыми к помещению в Бэклог Спринта (см. также Критерии Готовности к Разработке). Элементы достигают такого уровня прозрачности после активностей по Уточнению Бэклога Продукта, в ходе которого элементы снабжаются актуальной уточняющей информацией, разбиваются (декомпозируются) на более мелкие и конкретные, получают оценки размера, а также упорядочиваются.
Оценку размера элементов производят Разработчики, которые будут выполнять работу. Владелец продукта может влиять на Разработчиков, помогая им понять элементы и обсуждая компромиссы.
В Руководстве по Scrum 2020 появилась Цель Продукта, являющаяся commitment’ом для Бэклога Продукта.
См. также: Что такое продукт?
Практическое определение продукта от ScrumTrek.
Артефакты Скрама (Scrum Artifacts)
Материальное представление работы или ценности. В Скраме существует три артефакта: Бэклог Продукта, Бэклог Спринта, Инкремент.
Они спроектированы таким образом, чтобы обеспечить максимальную прозрачность ключевой информации, и чтобы все участники процесса имели единое понимание каждого из артефактов.
Бэклог – это упорядоченный по приоритету список работ, которые планируется выполнить с учетом знаний, имеющихся на данный момент.
Бэклог Спринта – это Цель Спринта, набор Элементов Бэклога Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта и достижения Цели Спринта. Служит для наглядного представления работы, которую Команда определила для достижения Цели Спринта.
Инкремент объединяет реализацию Элементов Бэклога Продукта, сделанную во время текущего Спринта. Является одним из трех Артефактов Скрама и отражает шаг на пути к Цели Продукта. Каждый Спринт должен включать минимум один Инкремент, чтобы считаться завершенным успешно.
Элемент Бэклога Продукта (Product Backlog Item)
Элемент Бэклога представляет собой часть работы, которую планируется сделать с учетом знаний, имеющихся на данный момент.
Элемент Бэклога Продукта – изменение, которое планируется выполнить в следующих Инкрементах продукта (например, фичи, функции, требования, усовершенствования или информация по исправлению дефектов). Элементы, расположенные в верхней части Бэклога Продукта, обычно более понятны и содержат больше деталей, чем те, что расположены ниже.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Как подготовить бэклог продукта с большим количеством зависимостей и не потратить время впустую
Привет, меня зовут Макс, я продакт команды Self-Service в мобильном приложении Тинькофф. У моей команды три основные цели по созданию сервиса: contactless, proactive и self-service.
Это значит, что мы стараемся сделать незаметными процессы для пользователя: убрать то, что можно убрать, и сделать незаметным то, что можно сделать незаметным. Проблемы решаем проактивно, если можем предсказать проблему, и упрощаем процесс за счет технологий.
Сегодня хочу рассказать о том, как мы в команде подходим к оценке задач и их приоритизации. А еще о том, как не делать лишнюю работу в условиях сложного продукта с большим количеством зависимостей.
Если вы отвечаете за разработку продукта, то в процессе изучения конкурентов, качественной и количественной аналитики, общения с коллегами или стейкхолдерами у вас появляются идеи, да и желающих накинуть их всегда хватает.
Представим, что вы всё записываете в заметки или блокнотик. У здорового продакта возникает логичный вопрос: какие задачи решать в первую очередь?
Главная задача хорошего бэклога — снизить уровень неопределенности и дать пользователю как можно больше ценности за меньшее время. Главное здесь — не ставить на первый план только цифры. Иначе за год у вас не появится ничего, кроме бэклога, если продукт большой и сложный. А через год бэклог уже устареет.
Раньше я использовал классическую ICE-методику, но в Тинькофф пришлось ее адаптировать. Сейчас расскажу как.
Мои пункты оценки бэклога
Название идеи — краткое название и суть того, что хочется сделать.
Основная гипотеза — как фича повлияет на пользователей и бизнес. Например: если мы добавим фичу «Изменить номер в МБ», то сократим обращения к оператору, время до целевого действия и количество касаний. То есть, количество шагов нужное пользователю, чтобы решить вопрос, сократится: мобильное приложение — бот — первая линия — бэк-офис и т. д. Форматы описания гипотезы есть в свободном доступе, их перечислять я не буду. Главное, чтобы вы и команда понимали, что делаете и зачем.
Ожидаемый результат — что должно получиться в итоге. Описание должно содержать критерии приемки задачи, а результат — конкретику. Например, «после реализации фичи пользователь может изменить контактный номер телефона без обращения в банк».
Вариант MLP/MVP. MVP — уже знакомое понятие, но недавно появилось еще одно — MLP: minimal loveable product. Уверен, вы и раньше использовали MLP, просто не называли его так. Важно подумать про то, как мы проверим нашу гипотезу и получим первые инсайды до того, как потратим ресурсы на целевое решение. Стоит использовать MLP, если финальное решение не зависит от результатов А/В-теста, есть возможность отдельно реализовать сценарий в MLP и вы уже сейчас можете поставить основной сценарий на прод без потери качества.
Результаты MLP помогут вам в приоритизации задач, добавят инсайтов и аргументов для правильного распределения ресурсов. Подробнее почитать про MLP можно в первоисточнике или на русском языке.
Критерии хорошего бэклога
Для определения приоритетов я использую ICE-метод. В ICE мы оцениваем идеи по трем параметрам: impact, effort и confidence.
Impact показывает, насколько идея положительно повлияет на ключевой показатель, который хотим улучшить.
Effort — оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
Confidence демонстрирует, насколько мы уверены в оценках влияния и легкости реализации.
Подробнее об impact
Чтобы определить влияние на метрики — составляем справочник. Мне нравится подход, в котором за единицу impact берется 1% от значения основных продуктовых метрик. Например, ваша основная продуктовая метрика — это CAC, и она равна 1500 ₽. Impact в этом случае будет равен 15 (1% от 1500).
Хорошо, если продуктовые метрики будут соответствовать трем основным критериям:
Показывать ценность продукта для потребителя.
Пересекаться с целями компании.
Понятно влиять на деньги.
В моем случае главная продуктовая метрика — доля активных клиентов мобильного приложения, которые не обращаются в поддержку.
Метрика верхнеуровневая и нечувствительная. Она не подходит для составления справочника, оценки работы результатов команды и отслеживания результатов эксперимента. Поэтому декомпозирую ее на более приземленную: доля активных клиентов мобильного приложения, которые не обращаются в поддержку по определенной тематике. За значение impact 1 я беру 10 000. Топ обращений не волатилен в течение года в относительных величинах. Под значениями 1—10 можно подразумевать что угодно — главное, чтобы значения были согласованы между собой.
Оценивая гипотезу, я выбираю соответствующее значение. Например, фича «изменение номера» в мобильном приложении сократит обращения к оператору по тематике «изменение данных» на N в месяц. Подставляем соответствующее значение impact.
В данном кейсе определить это число просто. Нам известно поведение пользователей. Сколько человек пишут в чат, чтобы изменить номер; сколько заходят на экран профиля, перед тем как обратиться; у какой доли обратившихся есть мобильное приложение и т. д. Но так бывает не всегда. Если вы хотите побольше погрузиться в то, как считать потенциальный impact, рекомендую книгу «Как измерить все, что угодно» Дугласа Хаббарда.
Позже каждая фича проходит через A/B-тест, где основные метрики для оценки эффективности — количество/доля обращений по тематике, время до целевого действия и количество касаний.
Подробнее о том, как выбрать основные продуктовые метрики, расскажу в следующей статье.
Подробнее о confidence
Составляем справочник по типу выше. Можно провести опрос и понять, как коллеги доверяют тому или иному факту. Еще тут хорошо работает логика. Если нужен пример того, как можно логически определить уверенность для гипотезы, спрашивайте в комментариях.
Чтобы ваша логика была понятна другим и не порождала много споров, можно составить справочник.
Подробнее про effort
Собираемся с теми, кто будет участвовать в разработке фичи, и пишем ожидаемое время разработки в часах/днях/неделях. Главное — использовать одну единицу измерения. Чем больше у вас будет информации по задаче к этому времени, тем точнее будет оценка.
С ICE все — дальше только ссылка на трекер с задачей: с подробным описанием идеи, дизайном, ссылкой на исследование и т. д.
В чем подвох описанного выше метода в реалиях нашей команды? Хороший продукт — это всегда сто один компромисс и умение управлять ими.
Продукт нашей команды — сервис. Сервис проходит через все бизнес-линии, продукты и процессы. На оценку и формирование бэклога может уйти немало времени.
Допустим, для оценки effort желательно иметь подробное описание задачи и дизайн, а это как минимум ресурс продакта, аналитика, дизайнера, коллег с бэка и других бизнес-линий. Их время можно потратить впустую, потому что может оказаться, что задача нереализуема в ближайшие полгода или год. Дизайн и аналитика устареют — работа проделана зря.
Из-за этого мои гипотезы проходят некий прескоринг перед тем, как попасть в бэклог. Его задача — быстро найти ограничения, постараться понять, где нужно решать проблему, и отправить на оценку в бэклог реализуемые задачи, а не мысли «звездочета».
Не каждой команде нужны все пункты ниже, но какие-то взять на вооружение точно можно. В книге «Вдохновленные: все, что нужно знать продакт-менеджеру» Мартина Когана описана часть ограничений. Ваша задача — как можно раньше понять, что может помешать вам выполнить вашу задачу, выписать эти причины-критерии и проскорить фичу по ним.
Мой прескоринг
Расскажу, что включает в себя мой прескоринг.
Бизнес-ограничения. Починив что-то в одном месте, можно сломать в другом и сделать в итоге хуже, чем было. Не все фичи нужно делать. Приходите к нашей команде, чтобы узнать, как фича может повлиять на клиентский опыт: негатив, обращаемость, отзывы и т. д.
Технические ограничения. Нужно убедиться, что фича реализуема в ближайшие 3—6 месяцев. При выборе периода исходим из скорости движения вашей команды. Это нужно для того, чтобы правильно определить приоритеты и делать то, что не заблокируется другими системами.
Дизайн-ограничения. Важно, чтобы фича не дублировалась с другой командой и на экране, где планируются изменения, не будет редизайна.
Поиск заинтересованных сторон aka бизнес-возможности. У наших задач много зависимостей от бэка, они затрагивают больше 10 команд. У этих систем много заказчиков и свои приоритеты. Чтобы задача попала в их бэклог с правильным приоритетом, нужно комплексно оценить ее. Возможно, вашей фичей вы положительно повлияете не только на метрики вашей команды, но и — о чудо! — на метрики других команд. Это очень важно, потому что поможет правильно оценить value и заручиться поддержкой других продактов.
Эксперт по процессу. Я записываю всех, кто может проконсультировать по тому или иному вопросу. Чтобы был понятен масштаб: в моей табличке уже больше ста человек. Это можно проделывать в голове или красиво оформлять в таблицу — все зависит от размера продукта и количества зависимостей.
Пример прескоринга фичи «изменение контактного номера в мобильном приложении»
Бизнес-ограничения. Явных ограничений нет, но нужно понаблюдать за метриками других продуктов, чтобы выяснить, как мы на них влияем.
Технические ограничения. Сама возможность изменить номер в мобильном приложении доступна не всем типам клиентов, а значит, нет смысла показывать ее тем, кто воспользоваться ею не сможет. Не подходит бэк для реализации фичи в мобильном приложении, так как текущий бэк создавался для операторов колл-центра.
Требуемые доработки в бэке:
Метод смены контактного номера телефона в сервисе изменения клиентских данных Person Profile.
Доработка сброса кэшей в API.
Рефакторинг многошаговой конфирмации в API.
Доработка сервиса лицевой биометрии.
Доработка конфирмации в core-компоненте.
За каждый пункт отвечают разные команды. Нужно пообщаться с каждой, чтобы понять сроки и запланировать задачу.
Требуемые доработки в чат-боте. Для разных типов клиентов нужен свой, особенный ответ чат-бота: одних ведем на экран в МП, вторых в КЦ.
Дизайн-ограничения. Планируется редизайн экрана другой командой, где будет точка входа в фичу — синк с командой, ответственной за экран.
Поиск заинтересованных сторон. Чтобы лучше спланировать бэклог и более точно посчитать велью фичи, я выделил четыре команды.
Команда origination: изменение контактного номера в мп может заэффектить долю клиентов с актуальным номером телефона, что повлияет на скорость обработки заявки и конверсию из заявки в открытие продукта.
Команда person profile: чем выше доля актуальных контактов, тем ниже расходы на их дедупликацию.
Команда Tинькофф Мобайла: один из продуктов экосистемы Тинькофф — мобильный оператор Тинькофф Мобайл. Как правило, контактный номер телефона в банке основной для клиента. NPV основного номера выше на X. Фича «изменить контактный номер в МП» поможет промотировать, сделать номер Тинькофф Мобайла контактным в банке, увеличить NPV Мобайла и не увеличить расходы на обработку обращений.
Экосистема: с фичей появится возможность делать новые рекомендации. Сейчас в тесте два кейса: клиенту не придется вводить новый контактный номер, так как мы уже его знаем, и клиенту не придется даже искать фичу «изменить номер», так как мы знаем, что он пришел его изменить (онлайн-триггеры), и можем предложить это раньше, чем он начнет искать, как это сделать, или задаст вопрос в чате.
Заключение
Прескорьте свои гипотезы до того, как они попадут в бэклог. Так можно сэкономить время, особенно в большой компании с множеством неизвестных.
Если ваш бэклог не отвечает на вопросы «Что, зачем и в каком порядке мы делаем?» — это не бэклог. Вам и членам вашей команды должно быть сразу понятно, почему вы делаете фичу А после фичи Б.
Если задачи выполняются, а метрики не меняются — значит, вы движетесь не туда.
Гайды и статьи в интернете — не истина в последней инстанции. Исходите из особенностей вашего продукта и той среды, где находитесь.
Что такое бэклог и как его уменьшить
Писать про сложные вещи всегда легче, чем про простые. В первую очередь потому, что про простые вещи ты всегда думаешь “ну это же элементарно, это все знают, что тут вообще можно рассказать?”. А потом посмотришь как это “элементарное” кто-нибудь применяет – и сразу вспоминается вот эта картинка:
Поэтому давайте сегодня поговорим про такую супер-базовую вещь, как бэклог. Опытные руководители проектов проходят мимо, новичкам и особенно тем, что только собирается в руководители проектов – читать обязательно. Попробую рассказать простыми словами и, надеюсь, бэклогов, которыми невозможно пользоваться, станет хоть немного меньше.
Возможно, какие-то моменты в тексте покажутся вам гипертрофированными, но, честное слово, я со всем этим сталкивалась на практике, иначе этого поста не было бы.
Что такое бэклог
Бэклог – это структурированный список актуальных задач, которые вам или вашей команде необходимо сделать, будь это функции в продукте, который вы разрабатываете, или обращения в техподдержку, которые вам необходимо выполнить. Ключевое слово тут – “актуальных”, а это значит, что бэклог регулярно пересматривается, изменяется и дополняется, чтобы соответствовать потребностям компании в текущий момент. Если упрощать еще больше, то бэклог – это просто аккуратно заполненная табличка с вменяемым и понятным всем членам команды описанием задач, статусом на текущий момент и выставленным приоритетом, которую команда регулярно отсматривает, выбрасывает оттуда то, что устарело, неактуально или несет слишком мало ценности относительно затрат времени или денег, отмечает то, что выполнено, и добавляет вновь появившиеся задачи.
Я против обобщений типа “бэклог – это только при разработке по SCRUM” или “бэклог нужен только в продуктовой разработке”. Бэклог – универсальная штука, необходимая не только в ИТ или в проектной деятельности, это инструмент упорядочивания и превращения в систему того, что “влетает” в вас и вашу команду из внешнего мира.
Это, конечно, пример, процесс может выглядеть как угодно. Важно, что систематизированный подход позволяет как ничего не потерять из бэклога, так и оптимизировать трудозатраты, делая оценку для новых элементов с определенной регулярностью, а не по мере их поступления. Плюс элементы бэклога имеют свойство “отлежаться и стать неактуальными”, и вот это “время тишины” между поступлением и оценкой позволяет рассматривать их уже на холодную голову. А еще при просмотре полного бэклога уже сложнее начать истерить на тему “этот элемент надо сделать срочно”, так как перед глазами одновременно еще десятки или даже сотни таких же элементов, конкурирующих за время и ресурс команды.
У меня вот есть отдельные бэклоги рабочих и личных задач, из которого я “надергиваю” себе задач на спринт (рабочий спринт у меня – неделя, личный – месяц, причем личный связан с бэклогом мужа через чат-бот в телеграме). Но это прямо тема для отдельного большого поста про практики личной эффективности.
Бэклог можно вести в Excel или в специализированном ПО типа той же JIRA, главное – чтобы была возможность структурирования и минимального анализа элементов в этом бэклоге. Из чего следует, что бэклог в Word – это очень, очень, очень плохая практика, даже если элементы этого бэклога раскрашивать текстовыделетелем или делать в Word табличку. Хотя после недавно виденного бэклога большой корпоративной аналитической системы в Outlook меня уже сложно чем-то удивить, наверное.
Какие бэклоги бывают?
Как уже было упомянуто выше, бэклог как инструмент используется много где. Самые популярные бэклоги, которые можно встретить:
Какая информация должна быть в бэклоге?
Программа минимум, чтобы бэклог можно было использовать без дергающегося глаза:
Наверное, это минимальный набор обязательных полей. Разумеется, он недостаточный для полноценной работы, просто остальные поля будут зависеть от специфики бэклога – если вы работаете по скраму, то там будут отсылки на эпики или оценки в сторипоинтах, если это бэклог запросов в техподдержку – то информация о затронутой системе или части системы, если это бэклог проектных инициатив – ФИО сотрудника, занимающегося проработкой, потенциальный бюджет и сроки и т.д. Вариантов миллион и, как правило, поля бэклога дополняются и актуализируются в ходе работы с ним.
Если тема бэклога вам близка, то много романтических подробностей для продвинутых РМов есть в посте про definition of ready, definiton of done и acceptance criteria.
Груминг и рефаймент бэклога
Если не вдаваться в разборки между адептами скрама и других методов разработки, то, по большому счету, оба термина – груминг бэклога (backlog grooming) или “зачистка” бэклога (backlog refinement) про одно и то же – это регулярный пересмотр бэклога, уточнение его элементов (причем какие-то элементы при этом могут быть объединены в один, а какие-то – разбиты на несколько), определение их ценности и трудоемкости и проч.
Каждая команда организует это так, как удобно ей, пример того, как может выглядеть этот процесс, я приводила выше. В SCRUM вроде бы есть условный пункт о том, что работа с бэклогом – это около 10% времени команды, но, на мой взгляд, цифра может отличаться в разы в любую сторону в зависимости от процесса.
Как разобрать бэклог? Что делать, если бэклог накопился на годы вперед?
Вообще очень большой активный бэклог – признак непрофессионализма и неумения приоритезировать. Да-да-да, а не признак недостатка ресурсов, как вы уже, наверное, подумали. Ну потому что у профессионала всегда есть опция эскалировать недостаток ресурсов с конкретными расчетами и договориться либо об урезании бэклога и дальнейшем контроле объема по определенным принципам либо о выделении новых людей в команду. А жевать на каждом ревью по 1000 строк бэклога, про которые даже инициаторы этих строка уже пару лет как забыли – ну такое себе, лучше уж сразу на hh.
Собственно, это и есть рецепт – если видите, что бэклог стал огромным неуправляемым монстром и теперь на ревью вам нужно по несколько часов каждый раз, или команда на ревью грустно вздыхает и говорит “ну а смысл обсуждать еще раз это все” – с этим нужно что-то делать.
Волшебной таблетки нет, все, что вы можете – это:
В комплексе это обычно срабатывает.
Мой внутренний голос говорит, что лично мне комфортно с бэклогом на полгода вперед, но, думаю, тут у всех свои границы.
Пример бэклога
Вроде бы все написано выше, и пример бэклога вряд ли добавит этому посту большой ценности, но все же – вот ниже пример бэклога по одной из моих производственных систем. Как видите – я очень уважаю условное форматирование и считаю, что это сильно упрощает восприятие. Кстати, забавно, но на мою первую работу руководителем проекта меня взяли за умение пользоваться условным форматированием в Excel, вроде бы банальная функция, но, как потом рассказывал мой непосредственный руководитель, с ней на тестовом задании мало кто справлялся.
Вот и все, что я могу сказать про бэклог, если вы нашли хоть что-то новое – значит, пара часов на пост была потрачена не зря.
Полезно? Нужны еще такие посты про базовые вещи или нет? И, если нужны, то про что было бы интересно почитать?