Backlog Refinement и AI: что реально меняется

Это первая статья из серии о том, как AI меняет классические встречи кросс-функциональной команды разработки. Ниже я начну с Backlog Refinement, а в следующих материалах отдельно разберу Planning, Daily, Review, Retrospective и затем соберу всё в итоговую обзорную статью.

Сразу уточню рамку: ниже я говорю про refinement как про регулярную командную сессию и практику уточнения backlog items, а не обязательно как про отдельное официальное Scrum-событие. Это важно для точности терминов: в Scrum Guide 2020 (RU PDF) refinement описан как ongoing activity, а не как самостоятельный event. В русской версии Scrum Guide 2020 эта мысль сформулирована прямо: уточнение Product Backlog — это постоянная деятельность по добавлению деталей, порядка и размера.

Backlog Refinement — одно из первых мест, где AI начинает приносить команде вполне осязаемую пользу. Он помогает быстрее собрать контекст, подготовить черновик постановки, быстро сгенерировать черновик критериев приёмки, найти похожие кейсы и сформулировать список открытых вопросов. Такой тезис уже поддерживается и более прикладными работами: например, в LLM-Assisted Requirements Engineering in Agile MDD отдельно валидировали генерацию acceptance criteria, а в индустриальном кейсе Acceptance Test Generation with Large Language Models пользователи отмечали, что AI-сценарии помогали замечать ранее пропущенные случаи. Но именно поэтому здесь особенно легко попасть в ловушку: перепутать хорошо оформленный черновик с действительно понятной задачей.

На мой взгляд, AI не упрощает refinement в том смысле, что команде теперь нужно меньше думать. Он скорее удешевляет самую дорогую ручную работу вокруг него — поиск, сводку, упаковку и первичную декомпозицию. А значит, ценность самого командного обсуждения не исчезает, а смещается: меньше времени уходит на то, чтобы собрать из хаоса что-то похожее на задачу, и больше — на то, чтобы понять, можно ли это вообще брать в работу.

“AI ускоряет не саму договорённость команды, а подготовку материала к ней”

Почему именно на Backlog Refinement изменения ощущаются в первую очередь

Если посмотреть на привычные командные ритуалы и встречи в Agile-практике, refinement оказывается одним из самых чувствительных к появлению AI. Причина довольно простая: вокруг refinement исторически было много ручной интеллектуальной рутины. Нужно собрать разрозненный контекст из документов, старых тикетов, переписок и памяти людей. Нужно превратить сырую бизнес-идею в понятный backlog item. Нужно сформулировать проблему бизнеса, сценарий, критерии приёмки, ограничения, открытые вопросы, зависимости и возможные edge cases.

Именно в этот слой AI попадает особенно хорошо. Это хорошо согласуется и с тем, как сегодня обсуждают применение LLM в requirements engineering: модели сильны в суммаризации, первичной структуризации требований, генерации черновиков и поддержке аналитической подготовки, но слабее там, где нужны доменная точность, трассируемость и ответственность за окончательные решения. В этом смысле refinement действительно становится одним из первых процессов, где польза AI ощущается быстро, а пределы его надёжности — почти сразу. Об этом хорошо пишут и в обзоре Challenges in applying large language models to requirements engineering tasks, и в свежем систематическом обзоре Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, и в более прикладной работе LLM-Assisted Requirements Engineering in Agile MDD.

Как refinement выглядел до AI

Если упростить, до AI refinement очень часто был процессом ручной сборки понимания. В backlog попадала не готовая задача, а скорее бизнес-намерение: улучшить onboarding, добавить напоминания, дать менеджеру новый отчёт, сократить количество просроченных обращений. После этого Product Owner, аналитик или кто-то из лидов начинал вручную собирать контекст: поднимались старые обращения клиентов, похожие фичи, ограничения текущей архитектуры, действующие статусы, существующие уведомления, UI-паттерны и всё остальное, что могло внезапно всплыть уже в обсуждении.

Дальше этот же человек или пара человек вручную пытались превратить собранное в первый черновик: сформулировать проблему бизнеса, описать сценарий, написать критерии приёмки, вынести открытые вопросы и обозначить возможные ограничения. Но даже если такой черновик уже существовал, встреча всё равно часто уходила на то, чтобы поднять контекст в голову всей команды. Product Owner заново объяснял, что хочет бизнес, аналитик рассказывал, что уже удалось выяснить, разработчики поднимали архитектурные ограничения, QA вытаскивал граничные сценарии, дизайнер и frontend обсуждали, нужен ли отдельный экран и где он вообще будет жить.

Один и тот же кейс: без AI и с AI

Чтобы не оставаться на уровне общих формул, возьму конкретный кейс. Продукт — B2B LMS-платформа для корпоративного обучения. Крупные клиенты назначают сотрудникам обязательные курсы по compliance, безопасности и внутренним регламентам. От бизнеса приходит запрос: нужно добавить автоматические email-напоминания сотрудникам, которые не завершили обязательный курс до дедлайна.

На первый взгляд это выглядит как простая задача про отправку письма. Но уже на первых шагах становится понятно, что на деле здесь много развилок: кого именно считать не завершившим курс, когда отправлять напоминания, как дедуплицировать отправки, как это настраивается клиентом, нужен ли лог отправок, что делать с time zone, какой язык письма брать и нужно ли исключать archived и deactivated users.

В режиме без AI команда приходила к этим вопросам в основном через длинную ручную подготовку и объёмный разговор на самой встрече. Сначала Product Owner поднимал клиентский контекст. Затем аналитик руками шёл по внутренним материалам: искал старые похожие запросы, смотрел notification service, проверял текущие статусы assignment’ов, наличие scheduler jobs, поля locale и timezone. Уже на этом этапе всплывали реальные ограничения: в системе есть email-шаблоны, но только для транзакционных писем; timezone хранится на уровне клиента, а не пользователя; логов отправки нет; отдельной модели напоминаний в продукте тоже нет.

После этого аналитик вручную собирал первый черновик постановки, но он всё равно оставался незрелым. Например, в нём могли быть не зафиксированы точные статусы, по которым нужно слать напоминания, логика дедупликации, минимальный scope UI, fallback по языку или границы первой версии. А уже на самом refinement команда дособирала задачу прямо во время разговора. Именно там выяснялось, что напоминания нужны только для mandatory-курсов, что статусы not_started и in_progress подходят, а expired лучше не брать в первую версию, что без журнала отправок support и customer success быстро утонут в вопросах, а без отдельной защиты будут дубли при повторном запуске jobs.

В режиме с AI тот же самый кейс выглядит иначе. Product Owner загружает в AI summary от Customer Success, последние клиентские обращения и сырой исходный запрос. AI быстро группирует боли клиентов, выделяет повторяющиеся ожидания и помогает оформить формулировку проблемы. Аналитик просит AI поднять всё, что связано с notification flows, assignment statuses, scheduler jobs, locale, timezone и похожими Jira tickets. Backend заранее прогоняет через AI описание текущей notification-архитектуры и просит предложить технический подход. Frontend и дизайнер быстро проверяют, куда логичнее встроить настройки и историю отправок. QA поднимает стартовый список edge cases и временных рисков.

Здесь обычно возникает естественный вопрос: а что, если AI что-то упустил? Насколько вообще можно верить такому summary, особенно когда база источников большая? Исследования и практические кейсы здесь дают довольно трезвую картину: LLM действительно могут ускорять генерацию user stories, черновиков критериев приёмки и первичных постановок, но качество результата сильно зависит от входного контекста, домена и последующей человеческой проверки. Поэтому полезно держать в голове и более прикладные работы вроде AI-Generated User Stories: Are They Good Enough? и LLM-Assisted Requirements Engineering in Agile MDD: они хорошо показывают, что генерация сильного черновика и готовность к разработке — не одно и то же.

По моему опыту работы с Cursor, в прикладных сценариях я довольно редко сомневаюсь в том, что модель способна собрать нужный первый проход по большому массиву источников. Гораздо важнее другое: насколько хорошо я сформулировал задачу, какие ограничения задал, какие уточняющие вопросы успел добавить и как именно организовал проверку результата. Когда у меня возникает сомнение, я не пытаюсь решить его вопросом «верю или не верю AI» — я просто доуточняю запрос, прошу отдельно показать источники, вынести спорные места, разделить факты и предположения или пересобрать ответ с другой рамкой. В этом смысле работа с AI очень похожа на коучинг: полезен навык задавать точные вопросы, которые не просто запускают генерацию, а направляют мышление модели в нужную сторону.

Это, конечно, мой личный опыт, а не универсальное правило. Возможно, я отдельно напишу ещё один материал именно про доверие к AI, качество уточняющих вопросов и управляемую проверку результата. Для refinement это особенно важно: чем больше база источников и чем убедительнее summary, тем выше риск перепутать сильную подготовку с уже проверенным пониманием.

“Чем больше база источников и чем убедительнее summary, тем выше риск перепутать сильную подготовку с уже проверенным пониманием”

В результате команда приходит на refinement уже не с сырой идеей, а с довольно сильной заготовкой: есть черновик user story, черновик критериев приёмки, открытые вопросы, список рисков, предварительный технический подход и UI-предложение. Поэтому сама встреча становится короче и предметнее. Команда уже не тратит столько времени на поднятие базового контекста и обсуждает в основном спорные места: включать ли expired, делать ли отдельный часовой пояс на пользователя, нужен ли журнал отправок в первом релизе, ограничиться ли фиксированными триггерами, как защититься от дублей и что считать границами версии v1.

В чем заключается прогресс команды?

Когда команда только начинает использовать AI, он в основном работает как быстрый генератор первого черновика. Но по мере зрелости следующий логичный шаг — перестать работать только с общей моделью и начать постепенно переносить в управляемый контекст команды то, что раньше жило только в памяти людей. Это могут быть продуктовые принципы, шаблоны критериев приёмки, частые причины отказа задачи на refinement, типовые edge cases, архитектурные ограничения, набор типовых уточняющих вопросов, внутренние регламенты организации, Definition of Ready и Definition of Done на уровне организации и команды, а также примеры хороших решений по похожим кейсам.

Тогда качество первого черновика действительно начинает расти. Не потому, что модель внезапно “поняла домен сама”, а потому, что команда научилась системно выгружать в неё собственные паттерны мышления, внутренние ограничения и правила проверки. И здесь refinement становится не только местом проверки задачи, но и местом, где команда постепенно обучает свой собственный AI-слой.

Что меняется по ролям

Ниже полезно смотреть не только на роли как на абстрактные функции, но и на конкретные действия в смоделированном кейсе с напоминаниями по обязательным курсам. Именно так разница между режимом без AI и с AI становится заметной по-настоящему.

Плюсы, риски и высвобождаемое время

Польза AI в refinement довольно ощутима. Быстрее собирается контекст, быстрее появляется черновик задачи, проще стартует обсуждение и лучше упаковываются итоги. Но именно в refinement риски AI тоже проявляются очень рано. Самый очевидный риск — ложная ясность. AI умеет делать аккуратные backlog items, которые хорошо выглядят визуально и структурно. Из-за этого команде проще обмануть себя ощущением, что задача уже понята, хотя в ней по-прежнему остаются продуктовые и технические дыры.

Здесь полезно назвать вещи своими именами. Во-первых, это automation bias и over-reliance — склонность принимать рекомендацию системы слишком охотно и переходить от активной проверки к более пассивному мониторингу. В NIST Generative AI Profile это прямо описывается как excessive deference to AI systems, а в эмпирическом исследовании Automation Bias in AI-Decision Support: Results from an Empirical Study показано, что высокий perceived benefit системы может повышать ложное согласие с её ошибками, тогда как качество обучения пользователей снижает вероятность такого эффекта. Во-вторых, это hallucination — правдоподобный, но не подтверждённый источниками вывод. Для refinement это особенно критично, потому что AI почти всегда работает через суммаризацию документов, тикетов и переписок, а значит риск не только в “красивом, но выдуманном черновике критериев приёмки”, а ещё и в тихом искажении исходного контекста. Именно поэтому в refinement AI чаще ошибается не в стиле текста, а в фактах контекста — и этот риск хорошо описан в работе On Faithfulness and Factuality in Abstractive Summarization. Практическое противоядие здесь довольно простое: просить модель отделять факты от гипотез, требовать ссылки на источники и строить summary так, чтобы его можно было быстро разобрать назад до документов, тикетов и решений команды.

Есть и ещё один слой риска — данные. В кейсе выше AI работает с клиентскими обращениями, внутренними описаниями системы и пользовательскими сигналами. Поэтому команде важно заранее договориться, что вообще можно передавать модели, а что нельзя. Для generative AI риск не ограничивается только промптом: персональные данные могут оказаться во входе, в выходе и даже через memorization/regurgitation модели. Поэтому, если в работе фигурируют персональные данные или чувствительный клиентский контекст, базовые принципы data hygiene должны быть обязательными: минимизировать объём данных в промптах, по возможности обезличивать вход, не тянуть в модель сырой экспорт без фильтрации, явно понимать цель обработки и не принимать на веру заявления провайдера вроде «мы не обрабатываем персональные данные» или «модель анонимна» без проверяемых организационных и технических контролей. Отдельно полезно заранее зафиксировать правовое основание обработки, минимально необходимый набор полей, роли и ответственность внутри процесса, а там, где это применимо, — требования к информированию субъектов данных. Если сценарий включает персональные данные и масштаб или риски заметны, имеет смысл заранее оценить, нужна ли DPIA, и отдельно зафиксировать это решение. В европейском контексте это хорошо согласуется и с принципами GDPR Article 5, и с практическими рекомендациями CNIL по AI system development, а также с EDPS guidance on Generative AI и EDPB Opinion 28/2024.

И здесь возникает ещё один важный вопрос: куда идёт высвободившееся время специалистов. Самый простой вариант — попытаться запихнуть в него ещё больше задач. Более зрелый — вложить эту экономию в качество решений, уменьшение технического долга, развитие внутренних шаблонов, обучение, документацию и хотя бы лучшее управление вниманием команды. В финальной обзорной статье серии я отдельно расскажу о том, что AI меняет не только процесс, но и культуру использования командного времени.

Новые скрытые затраты, которые нельзя игнорировать

Чтобы разговор об эффективности не выглядел слишком гладким, важно добавить и обратную сторону: AI редко даёт “чистую экономию” без новых типов работы. Часть времени теперь уходит на подготовку данных, настройку доступа к источникам, поддержку промптов и шаблонов, проверку источников, документирование решений и human review. Такой взгляд хорошо согласуется и с практиками risk management для generative AI: например, NIST Generative AI Profile делает акцент не только на выгоде автоматизации, но и на необходимости oversight, documentation и управленческого контроля.

Сценарная оценка трудозатрат на один Backlog Refinement (сценарно)

Ниже — не “средняя температура по рынку”, а сценарная модель одного и того же Backlog Refinement для одной и той же команды из семи человек: PO, BA, backend, frontend, QA, designer и Scrum Master. Это оценка одного крупного или заметно неопределённого backlog item, а не маленькой хорошо понятной story. Ценность этих цифр не в точности до минуты, а в сравнении структуры затрат: куда уходило время раньше и куда оно уходит теперь.

Дальше речь именно о человеко-часах на один крупный backlog item — подготовка, обсуждение и короткая доработка после встречи, — а не о длительности самой встречи как таковой. Сама встреча обычно тоже сокращается, но часть работы просто переезжает в асинхронную подготовку, уточняющие прогоны и обязательную ручную проверку.

Примечание к расчёту трудозатрат: исторически в Scrum Guide 2017 (RU PDF) refinement также описывался как ongoing process, и там встречался ориентир, что он обычно занимает не более 10% capacity команды разработки. В Scrum Guide 2020 (RU PDF) этого ориентира уже нет, поэтому таблицу ниже лучше читать не как норматив, а как сценарную модель для сравнения двух режимов работы.

Важно отдельно пояснить: колонка «С AI» ниже уже включает базовую новую работу, без которой этот сценарий не работает — подготовку входных данных, уточняющие запросы, первичную проверку summary, верификацию спорных мест и минимальную human review. То есть финальный профит в таблице — это не “грязная” экономия до учёта новых издержек, а уже более реалистичная сценарная оценка после их базового включения.

Чтобы эта оценка была воспроизводимой, её удобно считать по простой схеме: TAI = Tbase × ((1 − p) + p × s) + o, где Tbase — время без AI, p — доля ускоряемой работы, s — коэффициент ускорения на этой части, а o — новая работа на подготовку данных, уточняющие запросы и проверку результата.

Ниже — калиброванный пример именно под этот базовый сценарий. Его задача не доказать универсальную норму, а показать, как та же модель может воспроизвести цифры из таблицы для одного конкретного кейса. В реальной команде такие параметры лучше откалибровать по 3–5 последним Backlog Refinement и затем получить уже свой диапазон.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

Диапазон сценария: как может меняться профит

Какая новая работа уже учтена в сценарии с AI

Таблица ниже не отменяет итоговый профит из первой. Она просто расшифровывает, за счёт каких новых действий часть сэкономленного времени возвращается обратно в процесс — и почему даже после этого чистый эффект всё равно остаётся заметным.

Различия по этапам

Чек-лист качества AI-подготовки к refinement

Важно: этот Definition of Ready — внутренняя практика команды, а не часть Scrum Guide. Здесь он нужен как защита от ложной ясности, пропусков и размытой ответственности в AI-подготовке.

Definition of Ready для AI-черновика

• Отделены факты от предположений: команда понимает, что взято из источников, а что предложено моделью.
• Есть ссылки или понятные указания на источники для ключевых продуктовых и технических утверждений.
• Открытые вопросы не спрятаны под аккуратным текстом, а вынесены явно.
• Проверены доменные термины, статусы, ограничения, роли и зависимости.
• Для каждого ключевого утверждения понятен уровень доказательности: это факт из источника, рабочая гипотеза или предположение модели.
• Отдельно проверены edge cases, негативные сценарии и временные риски.
• Понятно, какие данные нельзя было передавать модели и какие меры data hygiene были применены.
• Назначены владельцы проверки по типам утверждений: бизнес-логика, архитектурная реализуемость, тестируемость и работа с данными.
• Команда договорилась, что AI-черновик — это сырьё для обсуждения, а не почти готовая задача.

Чтобы этот чек-лист не оставался слишком абстрактным, вот как он выглядел бы в нашем кейсе с email-напоминаниями:

• AI предлагает включить статусы not_started, in_progress и expired — команда явно помечает, что expired пока остаётся гипотезой, а не подтверждённым правилом для v1.
• В summary сказано, что уведомления нужно отправлять по тайм-зоне пользователя — backend сверяет это с источниками и подтверждает, что в текущей системе тайм-зона хранится только на уровне клиента, а переходы между часовыми поясами и DST надо отдельно проверить.
• AI добавил историю отправок как “очевидную” часть решения — Product Owner и BA отдельно решают, это обязательная часть первой версии или улучшение следующего релиза, потому что здесь есть ещё и вопрос аудита и нагрузки на support.
• QA получает не просто список edge cases, а конкретное задание проверить дубли при повторном запуске jobs, языковые fallback-сценарии, исключения для archived/deactivated users и негативные сценарии вокруг дедлайнов.
• Backend отдельно проверяет rate limits, throttling, deliverability и то, как система поведёт себя при повторных отправках и ошибках провайдера.
• PO и BA дополнительно валидируют политику уведомлений: кому можно слать напоминания, где нужны opt-out или клиентские исключения, и что считается допустимым поведением для mandatory-курсов.

Для такого кейса полезно отдельно проговорить и две практические вещи, которые часто всплывают уже ближе к продакшену: deliverability быстро превращается в нагрузку на support и customer success, если нет нормальной диагностики “почему письмо не дошло”, а quiet hours и календарные окна нередко оказываются не “дополнительной опцией”, а корпоративным требованием клиента.

Кто что проверяет вручную

Что я бы рекомендовал команде

• Не считать AI-черновик готовой задачей только потому, что он хорошо выглядит.
• Явно договориться, какие части контекста команда обязана проверять вручную до встречи, а какие — уже на самой встрече.
• Постепенно переносить в командный AI-слой собственные продуктовые и процессные паттерны, а не только использовать общий чат “как есть”.
• Не сокращать refinement механически только потому, что подготовка стала быстрее.
• Осознанно решать, куда идёт высвободившееся время: в качество, обучение, документацию, техдолг или восстановление внимания команды.

Отдельно важно помнить о границах применимости этого сценария. Эффект AI будет очень разным в зависимости от зрелости документации, доступности внутренних источников, доменной сложности продукта и того, насколько команда умеет превращать неявные знания в повторяемый контекст. Там, где исходные данные слабы, AI может ускорять упаковку, но не обязательно улучшать качество решений.

Вывод

Если совсем коротко, то главный эффект AI для refinement я бы сформулировал так: AI ускоряет не саму договорённость команды, а подготовку материала к ней. Именно поэтому refinement становится быстрее на входе: быстрее собирается контекст, быстрее появляется черновик, быстрее выявляются базовые вопросы и риски, быстрее упаковываются итоги.

Но это не делает refinement автоматически проще. Потому что как только стоимость подготовки падает, возрастает ценность того, что AI пока не умеет делать по-настоящему хорошо: понимать домен, чувствовать реальные ограничения, замечать ложную ясность, бережно обращаться с данными и помогать команде принимать осознанные компромиссы.

Поэтому лучший способ смотреть на AI в refinement такой: он убирает часть дорогой ручной работы вокруг практики, но делает ещё более важной человеческую проверку смысла. Чем проще стало производить backlog items, тем важнее стало понимать, какие из них действительно готовы к обсуждению, а какие просто хорошо выглядят. А уже в следующих статьях серии будет интересно посмотреть, как этот сдвиг влияет не только на процесс, но и на культуру использования командного времени.

Источники и ориентиры

• Scrum Guide 2020 (RU PDF)
• Scrum Guide 2017 (RU PDF)
• Challenges in applying large language models to requirements engineering tasks
• AI-Generated User Stories: Are They Good Enough?
• LLM-Assisted Requirements Engineering in Agile MDD
• Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review
• On Faithfulness and Factuality in Abstractive Summarization
• Automation Bias in AI-Decision Support: Results from an Empirical Study
• Examining human reliance on artificial intelligence in decision making
• NIST Generative AI Profile
• EDPB Opinion 28/2024 on certain data protection aspects related to AI models
• EDPS guidance on Generative AI (2025)
• GDPR Article 5
• CNIL: AI system development recommendations