Бэклог: ликбез
Всё, что вы хотели знать, но боялись спросить про самый эффективный скрам-инструмент
Бэклог — штука, которая нам в студии кажется такой же привычной, как утренний кофе или ежедневный стендап. Но недавно мы с ужасом подумали: а вдруг, это так только для нас? Встречайте статью для тех, кто «что-то слышал», «ну, бэклог — это ж просто…», «бэк. что?» и всех, кто не в теме. А если за бэклог вы всё-таки в курсе — освежите знания: вдруг, кругового бэклога в жизни не видели или не знаете, когда стоит провести плановый груминг (нет, это не про стрижку домашних животных мы сейчас).
Что такое бэклог
Возьмите свой список задач на день (он же есть?): там наверняка будут задачи в порядке приоритетов, которые важно сделать сегодня. Возможно, у вас также есть список дел на месяц или год, откуда вы «надергиваете» задачки на каждый день. Если так, то можно сказать, что фактически вы ведете бэклог.
Если не вдаваться в подробности, то бэклог — список всех задач и хотелок в порядке приоритета, которые планируется выполнить. Элементы списка гибкие: их можно менять, выбрасывать или добавлять новые по ходу дела. За это бэклоги любят противники толстых неповоротливых и формальных технических заданий.
Если не вдаваться в подробности, то бэклог — список всех задач и хотелок в порядке приоритета, которые планируется выполнить. Элементы списка гибкие: их можно менять, выбрасывать или добавлять новые по ходу дела. За это бэклоги любят противники толстых неповоротливых и формальных технических заданий.
Что о бэклоге говорит руководство по Скраму
Авторы скрамгайда описывают бэклог так:
Бэклог продукта — это упорядоченный список всего, что может понадобиться в продукте, и единственный источник требований для любого вида изменений продукта. Бэклог никогда не бывает полным: изначально он содержит базовые и самые понятные требования. С обновлением и развитием продукта, а также условий рынка и технологий бэклог меняется и становится более объёмным и исчерпывающим.
Бэклог спринта — набор элементов из бэклога продукта для исполнения в текущем спринте. Обычно включает хотя бы одну задачу из ретроспективы предыдущего спринта, план разработки очередной версии продукта и план достижения цели спринта.
Какое-то время бэклоги действительно были присущи только командам разработки, но этот простой и чёткий инструмент может пригодиться вообще в любой сфере: от списка обращений с предложениями в техподдержку до списков дел, которые нужно выполнить за конкретный промежуток времени (привет, планирование!). В продуктовых историях может быть даже отдельный бэклог для гипотез, если их много и важно проработать каждую и упорядочить их по приоритетам.
Бэклог продукта — это упорядоченный список всего, что может понадобиться в продукте, и единственный источник требований для любого вида изменений продукта. Бэклог никогда не бывает полным: изначально он содержит базовые и самые понятные требования. С обновлением и развитием продукта, а также условий рынка и технологий бэклог меняется и становится более объёмным и исчерпывающим.
Бэклог спринта — набор элементов из бэклога продукта для исполнения в текущем спринте. Обычно включает хотя бы одну задачу из ретроспективы предыдущего спринта, план разработки очередной версии продукта и план достижения цели спринта.
Какое-то время бэклоги действительно были присущи только командам разработки, но этот простой и чёткий инструмент может пригодиться вообще в любой сфере: от списка обращений с предложениями в техподдержку до списков дел, которые нужно выполнить за конкретный промежуток времени (привет, планирование!). В продуктовых историях может быть даже отдельный бэклог для гипотез, если их много и важно проработать каждую и упорядочить их по приоритетам.
Из чего состоит бэклог
Минимальный джентльменский набор: задача и её приоритет. Чем больше число — тем выше приоритет, а большие зазоры между числами (100, 200, 500, 1000, 10 000) дают место для маневра: всегда можно вписать ещё одну задачу между двумя другими. Общими факторами приоритизации могут быть: ценность для бизнеса, стоимость (или требуемые усилия) и сопутствующие риски (позитивное влияние реализации фичи или отрицательное влияние от её отсутствия).
Увы, обычно для разработки продукта двух полей в бэклоге маловато, поэтому там также могут появиться и другие колонки:
Развернутое описание задач и хотелок
Идеальный бэклог — тот, где по каждой строке однозначно ясно, что нужно делать. Из краткого описания хотелки не всегда можно уловить весь контекст, поэтому чем выше приоритет у задачи, тем подробнее должно быть её описание.
Развернутое описание задач и хотелок
Идеальный бэклог — тот, где по каждой строке однозначно ясно, что нужно делать. Из краткого описания хотелки не всегда можно уловить весь контекст, поэтому чем выше приоритет у задачи, тем подробнее должно быть её описание.
Чем ниже задача в бэклоге, тем меньше степень её проработки. И наоборот: чем выше задача в списке, тем более ясная формулировка ей нужна и тем выше должна быть её готовность к работе.
Предварительная трудоемкость
Может измеряться в часах, но чаще — в условных единицах, Story Point-ах: за 1 балл принимается самая простая задача из списка, а остальные оцениваются относительно неё.
Тип элемента
Задачи в бэклог могут добавляться по разным причинам: иногда это идеи и гипотезы, которые стоит проверить, иногда — обратная связь от пользователей, иногда — технические штуки, которые требуют доработок. Поэтому всегда неплохо сортировать их по типу с помощью условного форматирования, например.
Инициатор или хозяин задачи
Бэклог продукта — длительно развивающийся организм, который со временем только прирастает в объёме. Поэтому спустя 2−3 месяца довольно сложно бывает вспомнить, кто, когда и зачем предложил перекрасить кнопку в другой цвет, убрать из формы поле с описанием или прикрутить ещё один тип доставки. Такая колонка — как раз в помощь. Можно пойти ещё дальше и указывать дату добавления в бэклог и конкретного исполнителя задачи, но помните: чем больше колонок, тем сложнее содержать бэклог актуальным.
Может измеряться в часах, но чаще — в условных единицах, Story Point-ах: за 1 балл принимается самая простая задача из списка, а остальные оцениваются относительно неё.
Тип элемента
Задачи в бэклог могут добавляться по разным причинам: иногда это идеи и гипотезы, которые стоит проверить, иногда — обратная связь от пользователей, иногда — технические штуки, которые требуют доработок. Поэтому всегда неплохо сортировать их по типу с помощью условного форматирования, например.
Инициатор или хозяин задачи
Бэклог продукта — длительно развивающийся организм, который со временем только прирастает в объёме. Поэтому спустя 2−3 месяца довольно сложно бывает вспомнить, кто, когда и зачем предложил перекрасить кнопку в другой цвет, убрать из формы поле с описанием или прикрутить ещё один тип доставки. Такая колонка — как раз в помощь. Можно пойти ещё дальше и указывать дату добавления в бэклог и конкретного исполнителя задачи, но помните: чем больше колонок, тем сложнее содержать бэклог актуальным.
Пример бэклога с полями «Хозяин задачи», «Исполнитель», «Дата»
Статус
Колонка, опять же, пригодится для быстрой фильтрации, а ещё — для выборки задач на текущий спринт и для отслеживания прогрессов.
Колонка, опять же, пригодится для быстрой фильтрации, а ещё — для выборки задач на текущий спринт и для отслеживания прогрессов.
Пример бэклога с фильтрацией в колонке «Статус»
Екатерина
Исполнительный директор «Сибирикс»
Бэклог крупного продукта, который постоянно развивается, очень объемный. На проекте SingularityApp, например, он уже превышает 500 строк и не планирует на этом останавливаться. Здесь всегда много интерфейсных задач и новых фич под разные платформы. Какие-то идеи и задачи в бэклог добавляем мы сами, проводя аналитику и стратегические сессии. Какие-то добавляются туда по просьбам пользователей.
Мы пробовали вести бэклоги в разных системах, но пока остановились на простом табличном формате в GoogleDoc. Причина простая: таблицы очень быстрые. Нет лишних наворотов в интерфейсе, нет долгой обработки запросов. Поиск, сортировка, фильтры и математические формулы для приоритизации — то, что нам нужно. В этом бэклоге у задач разная степень детализации: это могут быть небольшие конкретные задачи и огромные фичи. Для каждой указывается тип, платформа и область, к которой задача относится. Для приоритизации используем технику ICE.
Если говорить о бэклоге спринта — то это уже максимально декомпозированные и конкретные задачи. Раньше для этого мы пользовались JIRA, но интерфейс Scrumban оказался удобнее с точки зрения работы с вложенностью задач и значительно шустрее.
Бэклог в заказной разработке — другая история. Обычно это декомпозиция задач, которая нужна нам для того, чтобы сделать проект по ТЗ. ТЗ, макеты, протоколы интеграции с заказчиком согласовываются, а бэклог из задач в этом случае — наша внутренняя кухня, которая не транслируется наружу. При работе по Time&Material процесс строится иначе, там не будет детального разжеванного ТЗ, только бэклог. И в этом случае он согласовывается с заказчиком.
Мы пробовали вести бэклоги в разных системах, но пока остановились на простом табличном формате в GoogleDoc. Причина простая: таблицы очень быстрые. Нет лишних наворотов в интерфейсе, нет долгой обработки запросов. Поиск, сортировка, фильтры и математические формулы для приоритизации — то, что нам нужно. В этом бэклоге у задач разная степень детализации: это могут быть небольшие конкретные задачи и огромные фичи. Для каждой указывается тип, платформа и область, к которой задача относится. Для приоритизации используем технику ICE.
Если говорить о бэклоге спринта — то это уже максимально декомпозированные и конкретные задачи. Раньше для этого мы пользовались JIRA, но интерфейс Scrumban оказался удобнее с точки зрения работы с вложенностью задач и значительно шустрее.
Бэклог в заказной разработке — другая история. Обычно это декомпозиция задач, которая нужна нам для того, чтобы сделать проект по ТЗ. ТЗ, макеты, протоколы интеграции с заказчиком согласовываются, а бэклог из задач в этом случае — наша внутренняя кухня, которая не транслируется наружу. При работе по Time&Material процесс строится иначе, там не будет детального разжеванного ТЗ, только бэклог. И в этом случае он согласовывается с заказчиком.
Обязательных полей — нет: всё зависит от проекта и процессов. Поэтому, если нужно добавить своих колонок — на здоровье. Лишь бы было удобно всегда держать их в актуальном состоянии.
Кто пишет бэклог
Кто должен писать бэклог — вопрос ситуативный. Иногда это сам менеджер. Иногда — менеджер вместе с разработчиком. Иногда — разработчик, если дело касается сложных технических аспектов. Иногда — аналитик (в идеале такой, который неплохо ориентируется в мире разработчика). Но если аналитик новичок, всегда имеет смысл давать ему в пару разработчика для написания бэклога, потому что сложные технические истории тот сам не вывезет. Как минимум — проверять бэклог после аналитика до того, как он пойдет в работу.
Добавлять хотелки в бэклог могут все заинтересованные в проекте лица, но за приоритеты задач отвечает всегда только Владелец продукта. Он же отвечает за периодический пересмотр бэклога, когда нужно выкинуть лишнее и устаревшее, обновить приоритеты или улучшить формулировки.
Добавлять хотелки в бэклог могут все заинтересованные в проекте лица, но за приоритеты задач отвечает всегда только Владелец продукта. Он же отвечает за периодический пересмотр бэклога, когда нужно выкинуть лишнее и устаревшее, обновить приоритеты или улучшить формулировки.
Какими бывают бэклоги
Всегда ли бэклог — это таблица? Необязательно. Чем успешнее становится продукт, тем он сложнее: больше функционала, больше пользователей и их обратной связи, больше технического долга, улучшений интерфейса, гипотез и оптимизаций — список стремится к бесконечности. В такой ситуации иногда простая и привычная таблица может оказаться не самым эффективным вариантом бэклога. И вот на что её можно заменить.
Бэклог как Customer Journey Map
Идея переложить задачи бэклога на пользовательские сценарии принадлежит Джеффу Паттону — тому самому автору книги «Пользовательские истории. Искусство гибкой разработки ПО», вышедшей по мотивам его давней статьи из блога.
Суть в том, чтобы строить бэклог вокруг пути пользователя — насколько продукт приближает его к достижению конкретных задач и целей. Такой подход даёт более целостное представление о том, как каждый элемент бэклога отвечает за выполнение пользовательской работы согласно теории JTBD.
Суть в том, чтобы строить бэклог вокруг пути пользователя — насколько продукт приближает его к достижению конкретных задач и целей. Такой подход даёт более целостное представление о том, как каждый элемент бэклога отвечает за выполнение пользовательской работы согласно теории JTBD.
Например, пользователь хочет оплатить товар в корзине. Учитывая довольно стандартную процедуру заказа, элементы бэклога могут быть такими:
А если он хочет искать товар на сайте, то был бы рад, если там будет:
- авторизация и вход в учетную запись (с сохранением данных, чтобы не вводить их заново);
- просмотр и подтверждение заказа до оплаты;
- оформление доставки и её варианты;
- оплата картой или платежной системой;
- письмо и/или sms с подтверждением заказа.
А если он хочет искать товар на сайте, то был бы рад, если там будет:
- поиск по наименованию;
- поиск по цвету;
- поиск по цене;
- поиск в конкретной группе товаров.
Карту пользовательских историй для зрелого продукта имеет смысл раскладывать на отдельные пользовательские персоны, цели, работы (JTBD) или проблемы пользователей.
Например, с точки зрения владельца интернет-магазина в сценарии оформления заказа покупателем в бэклоге важны следующие элементы:
Или, например, сайт, где публикуются статьи — для разных ролей будут разные сценарии и разные задачи для реализации:
- возможность отклонять заказы на сумму менее N рублей, потому что они невыгодны;
- возможность отказать покупателям за пределами РФ, потому что расходы на доставку делают эти заказы невыгодными;
- резервирование заказанных товаров на складе на 48 часов, чтобы другие покупатели видели реальные остатки в карточке товара;
- автоматическая отмена заказов, за которые не пришла оплата в течение 48 часов.
Или, например, сайт, где публикуются статьи — для разных ролей будут разные сценарии и разные задачи для реализации:
- клиенты хотят читать статьи, чтобы быть в курсе важных событий — нужны удобные фичи для поиска, закладок и комментирования;
- журналисты хотят писать статьи, чтобы их могли читать — нужен удобный инструмент для верстки статей;
- редактор хочет просмотреть статью перед публикацией и проверить её на опечатки — нужен режим предпросмотра;
- администратор хочет удалять статьи с сайта, чтобы бороться с оскорбительным контентом — нужен функционал в админ-панели для этого.
Бэклог как Customer Journey Map (источник)
Работая с пользовательскими историями, есть соблазн расписать их до уровня технических деталей. Но тогда теряется контекст и происходит дублирование:
- «Как пользователь, я хочу, чтобы серверная часть делала то-то и то-то»;
- «Как пользователь, я хочу интерфейс, который делает то же самое».
Хорошая пользовательская история должна приносить пользу конечному пользователю и затрагивать весь стек технологий (или такой его объём, чтобы функционал был рабочим). Истории, распотрошенные на технические детали, не представляют никакой ценности для пользователей: так, например, веб-интерфейс для них бесполезен, пока не соединен с базой данных.
Бэклог как воронка идей
Хороший вариант, если нужно визуализировать бэклог и физически ограничить количество его элементов. Подход поможет расставить приоритеты и сфокусироваться, с ним легко достичь гибкости без лишней формальной структуры.
Всё, что нужно — два поля:
- в левое отправляются все хотелки, которые нужно отсортировать по параметрам («сейчас, следом, скоро, позже» или «хорошо бы сделать, важно сделать, обязательно сделать»);
- в правом поле — три колонки по типу доски канбана: список дел, в процессе, уже сделано.
Бэклог как воронка идей (источник)
Фактически это сочетание канбана с дорожной картой, которое может быть очень удобным: вместо двух артефактов у вас всего один.
Бэклог возможностей
Призван собрать в себе все идеи, гипотезы, проблемы и потенциальные возможности. Каждый элемент такого бэклога затем пристально рассматривается, и если его признают жизнеспособным, тот переходит в бэклог разработки. И даже если в итоге хотелка не выживет — это будет отличный опыт, который поможет найти ещё больше новых возможностей для развития продукта.
Бэклог возможностей (источник)
Бэклог, основанный на типах (или классах) работ
Да, вы и так можете делить задачи в бэклоге на типы с помощью ярлыков или сортировок. Проблема лишь в том, что чем бэклог больше, тем сложнее это деление поддерживать. Решение — разделить один бэклог на несколько по типам работ. Тогда всё несделанное по техническому долгу будет лежать в одной кучке, а по интерфейсам — в другой.
Бэклог по типам работ (источник)
С одной стороны, идея логичная: каждый тип задач в своей группе. С другой, появляется проблема несогласованности: дизайнеры заботятся только о дизайне, спец по базам данных обособленно пилит базу данных, разработчик пишет код, а тестер тестирует. В итоге, чтобы получить прирост функциональности продукта, придётся ждать выполнения перечня задач по каждому отдельному бэклогу. Если будут недоделки по технической части или случится заминка с дизайном — продукт начнет буксовать.
Древовидный бэклог
Такой бэклог подходит для сложных продуктов с множеством различных функций, поскольку в таком формате проще визуально показать, как те взаимосвязаны между собой и как изменения в одном месте могут затронуть другие аспекты продукта. Один из классных примеров — дорожная карта австралийского банка Up в виде дерева. А если пойти ещё дальше, то можно составить дерево возможностей: на каждую проблему предложить несколько решений, а к ним — добавить эксперименты для проверки.
Древовидный бэклог (источник)
Бэклог как карта влияния (Impact Mapping)
В дереве решений каждая ветка — элемент незавершенной работы, здесь же под каждой веткой — ответы на вопросы: почему → кто → что → как.
Бэклог в виде карты влияния поможет визуализировать и продумать множество альтернативных путей пользователя, ведущих к конкретному результату. Но такой формат вряд ли справится с отображением в бэклоге технического долга или списка проблем в продукте для устранения.
Бэклог в виде карты влияния поможет визуализировать и продумать множество альтернативных путей пользователя, ведущих к конкретному результату. Но такой формат вряд ли справится с отображением в бэклоге технического долга или списка проблем в продукте для устранения.
Бэклог как Impact Mapping (источник)
Круговой бэклог
Круговой бэклог помогает наглядно категоризировать задачи и при этом сохранить целостность общей картинки. А экспериментируя с размером фрагментов можно физически ограничивать work in progress. Фактически, это такой же гибрид канбана с бэклогом как бэклог в виде воронки — только вид сверху :)
Круговой бэклог (источник)
Бэклог в виде воронки конверсии
Идеален для продуктов, где есть чёткая конверсия — например, в е-коммерс. Всё, что нужно — структурировать элементы согласно воронке конверсии. При таком формате бэклог объединяет количественные данные об отказах или потенциальных барьерах в воронке с потенциальными возможностями их улучшения. В таком виде бэклог сам по себе определяет приоритеты задач: на каком этапе воронки больше всего проблем — там и надо работать.
Такой тип бэклога подойдёт продуктам как на ранней стадии развития, так и более зрелым, поскольку держит в фокусе самые ключевые факторы, которые влияют на отклик пользователей — гадать над тем, что им важнее, здесь не приходится.
Такой тип бэклога подойдёт продуктам как на ранней стадии развития, так и более зрелым, поскольку держит в фокусе самые ключевые факторы, которые влияют на отклик пользователей — гадать над тем, что им важнее, здесь не приходится.
Бэклог в виде воронки конверсии (источник)
Автоматизация бэклогов в Сибирикс
Если на проекте есть четкое ТЗ, то менеджерам или аналитикам позже приходится вручную раздёргивать его на элементы бэклога — фактически, делать двойную работу. «Зачем?!» — подумали мы, и запилили интеграцию гугл-документов с сервисом Scrumban, который используем для ведения досок задач по проектам: теперь из готового аккуратно заполненного шаблона ТЗ задачи могут сразу улетать на доску, и никакого промежуточного бэклога в виде таблицы не требуется, как и времени на ручную конвертацию. Чистая экономия — от 2 до 6 часов на спринт.
 |  |
Где прячется импорт. Можно сразу выбрать нужный спринт на доске в Scrumban
 |  |
Импортировать можно хоть по одной задаче, хоть — оптом. Вложенность при этом сохраняется.
Тест-кейсы из ТЗ также импортируются и автоматически привязываются к конкретному блоку в задаче (раньше их приходилось прописывать в Scrumban вручную)
Полина
Руководитель проектов
История такая: на проекте Onebook заказчик решил прикрутить к сайту личный кабинет и сделать интеграцию с одним сервисом. А мы как раз в то время провели стратегическую сессию и решили создать крутой шаблон ТЗ, чтобы можно было кликнуть на кнопочку — и задачи вместе с постановками сразу улетали бы на доску задач проекта.
Так мы написали интеграцию Гугл-документов и Scrumban, которую обкатали на отдельно написанном небольшом ТЗ: в нём я выкинула всё лишнее и перекомпоновала описания так, чтобы те сразу превращались в реальные задачи в Scrumban, уже декомпозированные для разработчиков. Теперь ни менеджеру, ни аналитику не приходится перед началом спринта составлять отдельный бэклог из ТЗ.
В идеале мы хотим получить такую структуру ТЗ, которая легко трансформируется в бэклог на доске Scrumban просто нажатием кнопки импорта в гугл-документе. Сейчас обкатываем эту историю на нескольких проектах. Про очень масштабные — пока непонятно, насколько жизнеспособно, но для небольших проектов или спринтов с доработками — работает отлично!
Так мы написали интеграцию Гугл-документов и Scrumban, которую обкатали на отдельно написанном небольшом ТЗ: в нём я выкинула всё лишнее и перекомпоновала описания так, чтобы те сразу превращались в реальные задачи в Scrumban, уже декомпозированные для разработчиков. Теперь ни менеджеру, ни аналитику не приходится перед началом спринта составлять отдельный бэклог из ТЗ.
В идеале мы хотим получить такую структуру ТЗ, которая легко трансформируется в бэклог на доске Scrumban просто нажатием кнопки импорта в гугл-документе. Сейчас обкатываем эту историю на нескольких проектах. Про очень масштабные — пока непонятно, насколько жизнеспособно, но для небольших проектов или спринтов с доработками — работает отлично!
Что такое груминг бэклога и зачем он нужен
Каким бы ни был бэклог по форме и где бы он ни хранился, его постоянно нужно актуализировать — эта процедура лежит на плечах Владельца продукта и зовётся грумингом или рефайнментом. Груминг — термин адептов скрама, рефайнмент — сторонников других гибких методологий, но суть одна: это регулярный пересмотр и уточнение элементов, чтобы требования и хотелки к продукту не превращались в огромный неподвластный команде снежный ком.
Признаки, что бэклог пора пересмотреть
1. Количество добавленных элементов значительно превышает количество уже отработанных
Можете собрать статистику вручную, а можете использовать встроенные инструменты в Jira или Trello. Установите пороговые значения, когда количество задач станет для вас избыточным, и отслеживайте регулярно. Порог превышен — пора навести красоту.
Можете собрать статистику вручную, а можете использовать встроенные инструменты в Jira или Trello. Установите пороговые значения, когда количество задач станет для вас избыточным, и отслеживайте регулярно. Порог превышен — пора навести красоту.
Как может выглядеть статистика бэклога (источник)
Для этой цели, кстати, отлично подойдёт методика MoSCoW: сопоставляя объёмы работ из разных групп задач (must have, should have, could have, would like), легко понять, где список задач на данный момент избыточен.
Два сценария: в первом объём обязательных работ не выходит за рамки производительности команды, во втором — превышает (источник)
2. Большой средний возраст задач
Его можно отследить только, если фиксировать у каждого элемента изначально. В той же Jira есть инструмент статистики для отслеживания этого параметра. Причин устаревания задач может быть несколько:
- слишком много проблем по текущим элементам с наивысшим приоритетом;
- в целом слишком большой объём элементов;
- элемент на самом деле не ценный и не существенный, но выбросить пока жалко.
Общая рекомендация: если элемент лежит без дела больше 3 месяцев — пора задуматься.
3. Элементы в работе спорят с долгосрочными целями
Если не иметь взгляда «сверху», то легко застрять на выполнении задач, которые важны, но не глобально — из-за этого общий прогресс по бэклогу будет мизерным. Чтобы такого избежать, стоит классифицировать уже отработанные элементы бэклога за последние 120 дней, и посмотреть, насколько равномерно распределялась нагрузка. Категории могут быть такими:
- рост выручки;
- пользовательский опыт;
- вовлечение пользователей;
- технический долг;
- исправление багов;
- техподдержка и прочее.
Если потрудиться и составить диаграмму на основе этих категорий, то можно запросто оценить, на что тратится большая часть времени команды и как это соотносится со стратегией развития продукта.
Недельный объём работ из разных категорий в процентах от общего объёма элементов бэклога (источник). Очевидно, что куча времени тратится на исправление багов и очень мало — на пользовательский интерфейс.
Что включает груминг
Деление сложных элементов на более мелкие
Частая проблема — слишком большие элементы бэклога: если таких в спринте будет несколько, то даже выход за рамки отведенного времени по одному из них срывает сроки всего спринта. А если таких сложностей будет несколько? Груминг спешит на помощь: если грамотно разделить элемент на более мелкие, шансы на успех выше. Но вообще-то, конечно, это — первоочередная задача декомпозиции.
Удаление неактуальных элементов
Элементы бэклога могут устаревать по разным причинам:
Есть мнение, что огромный бэклог продукта — признак слабости его владельца. Поэтому, сокращая список элементов, вы фактически боретесь с двумя видами производственных потерь:
Чтобы навсегда распрощаться с элементом в бэклоге, задайте себе эти три вопроса:
Частая проблема — слишком большие элементы бэклога: если таких в спринте будет несколько, то даже выход за рамки отведенного времени по одному из них срывает сроки всего спринта. А если таких сложностей будет несколько? Груминг спешит на помощь: если грамотно разделить элемент на более мелкие, шансы на успех выше. Но вообще-то, конечно, это — первоочередная задача декомпозиции.
Удаление неактуальных элементов
Элементы бэклога могут устаревать по разным причинам:
- сменилось направление развития продукта;
- проблему уже исправили в рамках другой проблемы, случайно или намеренно;
- элемент устареет из-за другой функции, над которой планируется работать в ближайшем будущем;
- элемент уже не жизнеспособен из-за архитектурных изменений — тогда его нужно либо полностью переработать, либо удалить к чертовой матери;
- новые знания о пользователях, рынке или продукте говорят, что элемент на самом деле не решит проблему, ради которой его добавили в бэклог.
Есть мнение, что огромный бэклог продукта — признак слабости его владельца. Поэтому, сокращая список элементов, вы фактически боретесь с двумя видами производственных потерь:
- потерями из-за перепроизводства: планируем сделать гораздо больше, чем нужно — не проще ли делать то, что актуально прямо сейчас?
- потерями из-за запасов: лишние элементы в огромном бэклоге мешают сосредоточиться на самых важных вещах.
Чтобы навсегда распрощаться с элементом в бэклоге, задайте себе эти три вопроса:
1
Сколько элементов в бэклоге продукта сейчас (очевидно, что больше 300 — уже проблема)?
2
Сколько времени существует самый старый элемент (если он хранится нетронутым три года — может, чёрт с ним вообще)?
3
Сколько времени вы тратите на уточнение элементов, которые никогда не доходят до спринта, но всё ещё аккуратно хранятся в бэклоге (если вы тратитесь на такое — элементы того точно не стоят)?
Беспощадно избавляйтесь от всего, что:
- добавляет ненужные обязательства, ограничения или зависимости;
- добавляет ненужную сложность и раздувает функционал;
- дублирует предыдущие идеи и задачи полностью или частично (стоит объединить с уже существующим или дополнить его);
- устарело на данный момент;
- вызывает сложности с интерпретацией или пониманием гипотез;
- не отражает проблему, которую нужно решить.
Екатерина
Исполнительный директор «Сибирикс»
Частая проблема бэклогов, которые пишут по ТЗ — капитанство и копипастинг: элементы либо расписываются подробно на уровне бреда, либо просто бездумно копируются из ТЗ. Идеальный бэклог — тот, в котором все формулировки дружат с инфостилем и чётко описывают задачу: сделай вот это, чтобы пользователь мог сделать, увидеть, получить то-то.
Базовый принцип при составлении — пользоваться здравым смыслом и каждый раз думать о тех, кто будет выполнять задачи по этому бэклогу и о тех, кто в итоге будет пользоваться получившимся продуктом.
Базовый принцип при составлении — пользоваться здравым смыслом и каждый раз думать о тех, кто будет выполнять задачи по этому бэклогу и о тех, кто в итоге будет пользоваться получившимся продуктом.
Добавление новых элементов
Новые элементы могут добавляться в ответ на изменение бизнес-среды или рынка, появление нового видения продукта или новых комментариев от пользователей. А могут — потому что команда способна отработать больше элементов за спринт, чем предполагалось изначально. Если скорость работы — 20 элементов за спринт, то в бэклоге их должно быть хотя бы вдвое больше — чтобы было, из чего выбирать.
Переоценка приоритетов или корректировка оценок
Новые элементы могут быть важнее тех, что были самыми важными до этого. А оценки могут меняться из-за добавления новых задач в бэклог — поэтому придётся пересмотреть их у каждой задачи.
Также груминг бэклога может включать:
- уточнения по элементам, с которыми будут работать в ближайшее время;
- конкретизацию элементов с высоким приоритетом;
- редактирование или усиление существующих элементов;
- оценку элементов (если её ещё нет);
- группировку элементов по смыслу и создание подзадач.
Когда нужен груминг и сколько времени на него выделить
Обычно груминг проводится ближе к концу текущего спринта — это помогает убедиться, что бэклог готов к следующему спринту. Но обычно грамотный владелец продукта не ждет, пока запахнет жареным, и постоянно следит за актуальностью списка задач.
Если груминг вошёл в привычку, потребуется не больше 1,5 часов для 4-недельных спринтов (если ваши спринты короче — справитесь ещё быстрее). Но если груминг проводится впервые за несколько месяцев, готовьтесь выделить гораздо больше времени.
Если груминг вошёл в привычку, потребуется не больше 1,5 часов для 4-недельных спринтов (если ваши спринты короче — справитесь ещё быстрее). Но если груминг проводится впервые за несколько месяцев, готовьтесь выделить гораздо больше времени.
Если кратко
1
Бэклог — список задач к выполнению, отсортированный по приоритетам. Чем выше задача в этом списке, тем детальнее она должна быть проработана.
2
Минимальный набор полей для бэклога: задача и её приоритет. Если нужны другие детали — не вопрос, добавляйте на здоровье. Идеально, если будет условное форматирование в колонках.
3
Писать бэклог может руководитель проекта или продукта, аналитик или разработчик, но за приоритеты и актуальность задач всегда отвечает только Владелец продукта.
4
То, как выглядит бэклог — не столь важно, лишь бы было удобно им пользоваться. Но электронные таблицы, кажется, по-прежнему в топе.
5
Груминг бэклога — регулярный процесс пересмотра задач (обновление, добавление, удаление и актуализация).
6
Если задачи в бэклоге устарели, долгосрочные цели по-прежнему далеки или объём выполненных работ сильно меньше элементов в бэклоге — пришла пора груминга.
7
Груминг стоит проводить в конце каждого спринта (а лучше не запускать).
Ну вот, теперь вы настоящий бэклоговый гуру :)