Идеальный бэклог для Scrum-команды

• Рассказ о себе и опыте в системном анализе и разработке продуктов.  

• Определение бэклога как списка задач, которые могут принести пользу продукту.  

• Упоминание о неопределенности и важности задач в бэклоге.  

• Неупорядоченный список задач без строгого порядка.  

• Примеры: стикеры, заметки, почта.  

• Неупорядоченный список подходит для личных проектов, но не для командной работы.  

• Пример с канбан-доской.  

• Важность приоритезации задач для командной работы.  

• Ограниченный список задач как более жесткий и структурированный.  

• Три уровня зрелости бэклога: базовый, спринт и продукт.  

• Базовый уровень: бэклог спринта и продукта, владелец бэклога.  

• Спринт-бэклог как ограниченный список задач.  

• Признаки необходимости перехода на следующий уровень.  

• Введение дефинишина фрейде для улучшения качества задач в спринте.  

• Дефинишина фрейде как критерии для задач в спринте.  

• Описание юзер-истории и критерии приемки.  

• Техническая декомпозиция и готовность макетов.  

• Оценка задач и лимит на оценку.  

• Реализованность внешних зависимостей и согласований.  

• Доступность инфраструктуры и наличие согласований.  

• Введение этапа верификации дефинишина.  

• Задачи, прошедшие дефинишин, попадают в планирование спринта.  

• Задачи, не прошедшие дефинишин, отправляются на доработку.  

• Регулярные мероприятия для проработки задач.  

• Назначение ответственных за доведение задач до дефинишина.  

• Регулярный пересмотр дефинишина.  

• Бэклог делится на три уровня: непроработанные задачи, прошедшие дефинишин, и задачи в работе.  

• Метрики бэклога помогают понять, когда нужно прорабатывать задачи.  

• Проблемы с запасом задач и их реализацией.  

• Проверка гипотез и полезность задач для продукта.  

• Ответственность за определение полезности задач.  

• Аналитики помогают структурировать активность и понять направление развития продукта.  

• Не все задачи в бэклоге полезны, поэтому важно проверять гипотезы.  

• Пример: задача по рассылке ставок по кредитам клиентам банка.  

• Проверка гипотезы показала, что рассылка не увеличивает количество заявок на кредиты.  

• Проверка на прототипе, конкурентный анализ, уверенность продакт-менеджера.  

• Методология гроуд-хакинга и использование род мап.  

• Каждая команда определяет свои критерии проверки гипотез.  

• Бэклог делится на гипотезы, подтвержденные гипотезы, задачи, прошедшие дефинишн фрейм.  

• Уровень уверенности растет с каждым уровнем.  

• Метрика на гипотезы помогает понять, когда нужно переключать ресурсы на проверку гипотез.  

• Сессии по обсуждению гипотез можно совмещать с грумингами.  

• Команда может задавать вопросы и предлагать идеи.  

• Это особенно полезно для гибких и кроссфункциональных команд.  

• Структура бэклога индивидуальна и зависит от команды и процесса.  

• Важно остановиться на уровне, который подходит вашей команде.  

• Правильно структурированный бэклог помогает организовать рабочие процессы.  

• Аналитики должны проявлять инициативу и помогать формализовать задачи.  

• Продакт-менеджеры обычно рады, если задачи становятся более открытыми.  

• Важно не переусложнять процесс, если это не нужно.  

• В продуктовой команде без дедлайнов дедлайны в бэклоге не обязательны.  

• В случае с ТЗ дедлайны могут быть важны для выбора задач.  

• Важно учитывать дедлайны при выборе людей для доведения задач до дефинишн фрейма.  

• Проработка задач до дефинишна фрейде не должна занимать больше одного спринта.  

• Если задача слишком сложная, её можно декомпозировать на более мелкие части.  

• Важно стремиться к завершению задачи до дефинишна фрейде за один спринт разработки.  

• Прототипы для проверки гипотез должны включаться в бэклог.  

• Эти задачи могут не оцениваться в стори поинтах, но должны быть включены в работу команды.  

• Процент времени на такие задачи можно увеличивать, если гипотез не хватает.  

• Задачи должны ставиться на конкретных участников команды до окончания проверки гипотезы.  

• Важно учитывать соотношение количества аналитиков и разработчиков.  

• Дорна помогает закрепить контракт между аналитиками и разработчиками.  

• Качество списка критериев можно оценить на ретро.  

• Проблемы с задачами могут быть связаны с неправильным выбором критериев.  

• Ретро — идеальное время для изменения списка критериев.  

• Можно использовать существующие критерии и дополнять их своими.  

• Начинать лучше с небольшого списка, чтобы избежать перегрузки.  

• Проверка гипотезы отличается от коммерческого обоснования задачи заказчикам.  

• В случае с заказчиком, который сам формирует гипотезы, продуктовая команда не видит всех задач.  

• Удобно использовать отдельные скоупы для разных стадий гипотез.  

• Можно использовать физическую доску для наглядности.  

• Со статусами задач это можно связать, но не обязательно.  

• При возникновении срочных задач от продакта, нужно приостановить активность по другим задачам.  

• Важно заранее обсуждать с продактом, какие задачи можно отложить.  

• Все идеи заносятся в бэклог, но перед этим обсуждаются с продактом.  

• Продакт может сразу обсудить идеи или сделать это позже.  

• Если продакт дает добро, задача попадает в бэклог в формате гипотезы.  

• Проверка гипотез должна включаться в бэклог спринта.  

• Это помогает поддерживать баланс между проверкой гипотез и другими