Груминг и Definition of Ready

Почему команды, которые «просто берут задачи из бэклога», регулярно застревают на третий день спринта — и что за встречу они пропустили.

Груминг (он же backlog refinement, «уточнение бэклога») — регулярная работа команды над верхушкой бэклога: разобрать, уточнить, порезать и оценить истории до того, как они попадут в спринт. Definition of Ready (DoR) — согласованный чек-лист, отвечающий на вопрос «можно ли эту историю уже брать в работу».

Зачем это нужно: цена «разберёмся по ходу»

Типичная сцена. Планирование спринта, команда набирает задачи. Берут историю «Уведомления о статусе заказа» — вроде понятно. Оценивают в 5, кладут в спринт, расходятся довольные.

Вторник. Разработчик открывает задачу и обнаруживает: не решено, куда шлём уведомления — в почту, push, SMS или всё сразу. Идёт к владельцу продукта — тот на встречах до четверга. В четверг выясняется, что нужны push, но их шлёт внешний сервис, доступа к которому у команды нет, и заявку на доступ рассматривают неделю. Спринт закончился, история не сделана, команда объясняет на обзоре, почему «почти готово».

Всё это можно было выяснить две недели назад за пятнадцать минут. Ровно для этого и существует груминг: он переносит выяснение неизвестного из спринта (где неизвестное стоит дорого — оно блокирует уже начатую работу) в спокойное время перед спринтом (где оно стоит копейки).

Формально Scrum Guide не называет груминг отдельным событием — там сказано, что refinement это непрерывная деятельность, на которую уходит примерно до 10% времени команды. На практике почти все команды закрепляют под неё регулярный слот: раз в неделю на час или дважды по полчаса.

Что происходит на груминге

Груминг — это не «встреча, где владелец продукта зачитывает задачи». Это работа команды над материалом. Обычно делают четыре вещи:

Разбирают только верхушку бэклога — то, что вероятно попадёт в ближайшие один-два спринта. Уточнять до критериев приёмки историю, до которой очередь дойдёт через полгода, — чистая трата времени: к тому моменту требования изменятся, а половину задач вообще отменят.

Хороший груминг выглядит так: владелец продукта за минуту рассказывает историю, дальше 10 минут вопросов от команды, кто-то тут же правит карточку, в конце — оценка. Если оценить не получилось — это результат: значит, нужен спайк (короткое исследование) или ответ от смежников, и это фиксируют прямо сейчас, а не через две недели.

Definition of Ready: фильтр на входе в спринт

DoR отвечает на один вопрос: что должно быть верно про историю, чтобы команда согласилась взять её в спринт? Это общая договорённость команды, а не приказ сверху. Обычно она умещается в 5–8 пунктов и висит на видном месте.

DEFINITION OF READY — команда «Заказы»

Историю можно брать в спринт, если:

  [ ] Сформулирована как user story: роль — действие — ценность
  [ ] Есть критерии приёмки (Given/When/Then), не меньше 2 сценариев
  [ ] Разобраны краевые случаи: пустое состояние, ошибка, права доступа
  [ ] Внешние зависимости закрыты:
        — нужные API существуют и доступны на стенде
        — доступы/ключи получены, а не «запрошены»
  [ ] Есть макет или явная пометка «дизайн не нужен»
  [ ] Команда оценила историю, разброс оценок сошёлся
  [ ] Оценка не больше 8 story points (иначе — режем)

Если хоть один пункт не выполнен — история остаётся
в бэклоге и возвращается на следующий груминг.

Обратите внимание на пункт про зависимости: получены, а не «запрошены». Это выстраданная формулировка. «Доступ запрошен» — это ноль гарантий и та самая мина, на которой подрывался спринт из примера выше.

Важный нюанс, который часто понимают неправильно: DoR — не жёсткие врата с охраной. Если команда превращает его в бюрократический шлагбаум («в карточке не проставлено поле „компонент“ — не возьмём»), она получает второй Waterfall: аналитик месяц пишет идеальные требования, разработчики ждут. Смысл DoR в другом — это предохранитель от известных болей. Каждый пункт там появился потому, что команда однажды обожглась. Нет боли — нет пункта.

Вопросы, которые задают задаче на груминге

Практический набор, который стоит просто держать под рукой. Хорошая история переживает эти вопросы без потерь; плохая рассыпается на первом же.

• Кому это нужно и что он не может сделать сегодня? Если ответа нет — историю, возможно, не надо делать вовсе.
• Как мы поймём, что готово? Прямой путь к критериям приёмки. Ответ «ну, когда будет работать» не принимается.
• Что происходит, когда данных нет? Пустой список, первый вход, ноль заказов — самый забываемый экран в индустрии.
• Что происходит при ошибке? Внешний сервис лёг, сеть отвалилась, платёж не прошёл — что видит человек?
• Кто это может делать, а кто нет? Права доступа. Может ли обычный пользователь дёрнуть чужой заказ, подставив id в URL?
• Сколько их будет? 10 записей или 10 миллионов? От ответа зависит, нужна ли пагинация и индекс в базе — и оценка меняется втрое.
• От кого мы зависим? Чужая команда, внешний API, юристы, дизайн. Всё, что вне контроля команды, — источник срыва.
• Что будет, если этого не делать? Отрезвляющий вопрос. Иногда честный ответ — «ничего», и история отправляется в корзину.
• Можно ли сделать это меньше? Что минимально даст ценность? Часто выясняется, что 80% пользы — в 20% задуманного объёма.

Как это работает

Бэклог полезно представлять как воронку, где истории движутся сверху вниз и по дороге становятся всё детальнее:

Идея / эпик        →  формулировка в одну строку, без деталей
     ↓ груминг
История            →  роль-действие-ценность, вопросы заданы
     ↓ груминг
Готовая история    →  критерии приёмки, оценка, зависимости сняты
     ↓ проходит Definition of Ready
Спринт             →  команда берёт в работу
     ↓ работа команды
Готово             →  проходит Definition of Done, можно выкатывать

Отсюда простое правило здорового бэклога: ближе к верху — детальнее. Две-три верхние истории должны быть готовы к работе хоть завтра. То, что лежит в середине, — с прикидочной оценкой. Внизу — просто идеи одной строкой, и это нормально.

Ещё одна метрика здоровья: команда должна входить в планирование с запасом готовых историй примерно на полтора спринта. Меньше — планирование превращается в груминг и растягивается на четыре часа. Больше — команда тратит время на детализацию того, что успеет протухнуть.

И да, DoR и DoD — родственники, но отвечают на разные вопросы. DoR: «можно ли начинать?». DoD: «можно ли считать законченным?». Один охраняет вход в спринт, другой — выход.

Частые ошибки

• Груминга нет вообще. «Разберёмся на планировании» — и планирование превращается в четырёхчасовой марафон, где команда одновременно выясняет требования, спорит про краевые случаи и пытается оценивать. Устают все, качество решений — соответствующее.
• Груминг превратился в монолог. Владелец продукта зачитывает карточки, команда молча кивает и расходится. Вопросов ноль. Это не груминг, это чтение вслух: ценность встречи ровно в том, что команда задаёт неудобные вопросы.
• Грумят весь бэклог подряд. Три часа детализируют историю, которая стоит сотой в списке. К моменту, когда до неё дойдёт очередь, рынок изменится, и работа уйдёт в мусор.
• DoR как бюрократия. Чек-лист из 20 пунктов, включая «проставлен epic link» и «согласовано с четырьмя отделами». Ready не наступает никогда, команда начинает саботировать процесс и таскать задачи в спринт в обход.
• Оценивают, не поняв. Команда ставит 5, потому что «ну, наверное, как в прошлый раз». Признак: при покере планирования оценки разъезжаются от 2 до 13. Это не повод усреднять — это повод разговаривать. Расхождение почти всегда значит, что люди поняли задачу по-разному.
• Забывают выбрасывать. Бэклог из 400 задач, половина написана два года назад людьми, которые уже уволились. Такой бэклог никто не читает и, значит, никто им не управляет. Не бойтесь удалять: если идея правда важная, она вернётся.

Итоги

• Груминг — регулярное уточнение верхушки бэклога до спринта. Он переносит цену неизвестности туда, где она дёшева.
• На груминге историю уточняют, режут, оценивают и — иногда — честно выбрасывают.
• Детализация растёт снизу вверх: внизу бэклога идеи в одну строку, наверху — истории, готовые к работе завтра.
• Definition of Ready — командный чек-лист «можно брать в спринт»: есть критерии приёмки, сняты зависимости, есть оценка, история достаточно мала.
• DoR — предохранитель от собственных болей, а не пропускной пункт. Каждый пункт заслужен собственным факапом.
• Держите набор вопросов к задаче: кому нужно, как поймём что готово, что при пустых данных и при ошибке, кто имеет право, сколько данных, от кого зависим, можно ли меньше.