Как происходил груминг на текущем проекте?

Груминг бэклога на текущем проекте

Груминг (refinement) бэклога — это одна из ключевых функций бизнес-аналитика, и я всегда уделяю этому особое внимание. Расскажу о том, как мы организовали этот процесс.

Цель груминга

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

• Истории хорошо определены и понятны
• Оценены по сложности (Story Points)
• Имеют критерии приёмки
• Выявлены зависимости и риски
• Приоритизированы в правильном порядке

Структура груминга на нашем проекте

1. Еженедельные сессии груминга (1-2 часа)

Мы проводили груминг два раза в неделю:

• Вторник, 10:00 — основная сессия груминга (1.5 часа)
• Четверг, 15:00 — доп-сессия для уточнений (30 минут)

Участники:

• Я (бизнес-аналитик) — фасилитатор
• Product Manager — вносит требования и приоритеты
• Tech Lead — оценивает сложность
• 2-3 разработчика — задают технические вопросы
• QA Engineer — определяет критерии приёмки

2. Подготовка перед грумингом

За день до сессии я:

• Изучаю требования от PM
• Пишу черновик user story с описанием, AC, и acceptance criteria
• Рисую простые диаграммы для визуализации
• Выявляю потенциальные вопросы и блокеры
• Добавляю в agenda ссылки на дизайны, аналитику и другой контекст

Процесс груминга во время сессии

Шаг 1: Представление истории (5-10 минут)

Я рассказываю:

• Что делает пользователь (user story в формате "As a... I want... So that...")
• Почему это важно (бизнес-ценность)
• Как это связано с другими работами

Пример:

As a customer
I want to save items to my wishlist
So that I can purchase them later

Шаг 2: Уточнение деталей (10-20 минут)

Основные вопросы:

• Дизайн: как это выглядит? (показываю макеты)
• Данные: какие данные нужны? (обсуждаем схему БД)
• Зависимости: зависит ли это от чего-то ещё?
• Граничные случаи: что если пользователь X? Если Y?
• Интеграции: требуется ли API, аналитика, письма?

Шаг 3: Определение критериев приёмки (5 минут)

Вместе с командой пишем SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound):

Criteria of Acceptance:
✓ Пользователь может добавить товар в wishlist из карточки товара
✓ Wishlist отображается в личном кабинете
✓ Товары сохраняются в БД
✓ При добавлении товара показывается toast-уведомление
✓ Пользователь может удалить товар из wishlist
✓ На мобильном работает также как на десктопе
✓ Нельзя добавить один товар дважды (дублирование)

Шаг 4: Оценка сложности (5 минут)

Используем Planning Poker:

• Каждый разработчик показывает карточку с оценкой (1, 2, 3, 5, 8, 13...)
• Если оценки совпадают — берём эту цифру
• Если разные — обсуждаем почему (может быть риск, который заметил только один)
• Итоговая оценка = согласованное значение

Шаг 5: Выявление рисков и зависимостей (3-5 минут)

Вопросы:

• Есть ли technical debt, который может помешать?
• Нужна ли работа в другой системе?
• Есть ли зависимость от других историй?
• Может ли это сломать что-то существующее?

Примеры из практики

История 1: Простая

As a customer
I want to apply a promo code at checkout
So that I can get a discount

Estimate: 5 Story Points
Dependencies: Payment API integration (already done)
Risks: None
Status: Ready for Sprint

История 2: Сложная

As a customer
I want to see personalized product recommendations
So that I can discover products I might like

Estimate: 13 Story Points
Dependencies: Recommendation engine (in progress), Analytics tracking
Risks: Performance impact if recommendation algo is slow
Mitigation: Cache results, implement pagination
Status: Ready for Sprint (с условием, что recommend engine готов)

Управление очередью историй

Каждую сессию я:

• Удаляю устаревшие истории (которые потеряли актуальность)
• Переупорядочиваю приоритеты на основе требований PM
• Разбиваю большие истории (>13 points) на меньшие
• Объединяю микро-истории (<2 points) если они связаны

Метрики груминга

Мы отслеживали:

• Velocity: среднее количество points за спринт (~50)
• WIP (Work In Progress): груминили на 2-3 спринта вперёд
• Ready rate: процент историй, готовых к спринту (целевой — 90%+)
• Story points accuracy: сколько points мы планировали vs реально сделали (целевой — 80%+)

Результаты

Благодаря систематическому грумингу:

• Спринты стали предсказуемыми — velocity стабилизировалась
• Меньше переделок — чёткие критерии приёмки
• Меньше surprises — риски выявлены на ранней стадии
• Команда довольна — нет цейтнота и неясностей в спринте
• PM может планировать — знает, что делается в какой спринт

Совет

Груминг — это инвестиция в качество. Сэкономив 2 часа на грумингу, вы потратите 10 часов на переделки в спринте. Делайте груминг регулярно и серьёзно!