Работа с бэклогом: уточнение, декомпозиция, пользовательские истории, оценка

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

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

Эта статья — про то, как поддерживать бэклог в состоянии, при котором Scrum вообще способен работать. Мы разберём: что про бэклог написано в Scrum Guide (сюрприз — очень мало), какие практики выросли вокруг него, где практики полезны, а где превращаются в бюрократию, и что из этого спрашивают на PSM I.

Дисциплина различения. Дальше в тексте я буду явно помечать три уровня: [SG] — прямо написано в Scrum Guide; [практика] — распространённый приём, которого в Guide нет и который на экзамене нельзя выдавать за правило; [антипаттерн] — так делают часто, и это вредит. Умение различать эти три уровня — половина успеха на PSM I и почти весь успех в реальной работе.

Что Scrum Guide действительно говорит о Product Backlog

Начнём с текста. Раздел о Product Backlog в редакции 2020 года занимает около двадцати строк, и в нём нет ничего из того, что обычно называют «работой с бэклогом» в вакансиях.

[SG] Определение. Product Backlog — это «развивающийся упорядоченный список того, что нужно для улучшения продукта. Он является единственным источником работы, выполняемой Scrum-командой».

Три слова здесь несут всю нагрузку:

• Развивающийся (emergent). Бэклог не пишется один раз. Он живёт, потому что живёт понимание продукта. Замороженный бэклог — признак того, что команда перестала учиться.
• Упорядоченный (ordered), а не «приоритизированный». Формулировку сменили осознанно. Приоритет — это про важность. Порядок — про последовательность, в которой учитываются ещё и зависимости, риск, потребность в раннем обучении. Элемент может быть менее важным, но идти выше, потому что снимает неопределённость для трёх других.
• Единственный источник работы. Всё, что команда делает, находится в бэклоге. Задача, прилетевшая в личку тимлиду, — не работа команды, а невидимая нагрузка, которая ломает прозрачность.

[SG] Обязательство. Product Backlog имеет обязательство (commitment) — цель продукта (Product Goal). Она описывает будущее состояние продукта и служит долгосрочной мишенью. Про артефакты и обязательства подробно — в статье Артефакты и обязательства.

[SG] Уточнение. «Уточнение Product Backlog — это акт разбиения и дальнейшего определения элементов Product Backlog на более мелкие и более точные. Это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер. Атрибуты часто различаются в зависимости от предметной области работы».

Три следствия, которые обязательно всплывут на экзамене:

1. Уточнение — не событие Scrum. Событий ровно пять: спринт, планирование спринта, дейли-скрам, обзор спринта, ретроспектива. Уточнение — деятельность, которая происходит внутри спринта в удобном команде режиме.
2. В Guide нет нормы «не более 10% ёмкости». Она была в редакции 2017 года и удалена в 2020-й. Если вам на экзамене предлагают вариант с процентом — это ловушка на знание актуальной версии.
3. Атрибуты элементов (оценка, описание, порядок) существуют, но их набор Guide не фиксирует.

[SG] Готовность. «Элементы Product Backlog, которые могут быть сделаны Scrum-командой в течение одного спринта, считаются готовыми к выбору на событии планирования спринта. Обычно они приобретают такую степень прозрачности после уточняющих активностей». Обратите внимание: критерий готовности — помещаемость в спринт с доведением до Definition of Done, а не заполненность полей в трекере.

[SG] Кто отвечает. Product Owner отвечает за формулирование элементов, за их порядок, за прозрачность бэклога и за цель продукта. При этом: «Product Owner может выполнять эту работу сам, а может делегировать ответственность другим. Независимо от этого, Product Owner остаётся подотчётным». То есть уточнять может кто угодно, отвечает — один человек.

[SG] Оценка. «Разработчики, которые будут выполнять работу, отвечают за оценку размера. Product Owner может влиять на разработчиков, помогая им понять и выбрать компромиссы». Это самая часто нарушаемая строчка Guide на практике и самая любимая на экзамене.

Чего в Scrum Guide нет вообще. Не встречаются слова: пользовательская история, story points, planning poker, velocity, epic, grooming, Definition of Ready, backlog refinement meeting. Всё это — практики из XP, Kanban и индустриального фольклора. Они бывают полезны, но на PSM I любой ответ, объявляющий их обязательными, неверен.

Градиент детализации: почему бэклог не список равных задач

Главная концептуальная ошибка новичка — представлять бэклог как плоский список задач. На самом деле это конус: чем ближе элемент к исполнению, тем он мельче и точнее; чем дальше — тем крупнее и туманнее. И это не недостаток, а экономически правильное поведение.

Логика простая. Детализация стоит денег: время аналитика, дизайнера, разработчиков на обсуждение. Детализация того, что будет делаться через полгода, почти наверняка пропадёт зря — приоритеты изменятся, обратная связь по первым инкрементам перевернёт представление о продукте. Это классические потери из бережливого производства: запас незавершённой аналитики так же вреден, как запас непроданных деталей на складе.

Обратная крайность так же плоха: если над «красной линией» пусто, планирование превращается в четырёхчасовую аналитическую сессию, а команда берёт в спринт то, чего не понимает.

[практика] Ориентир запаса — примерно полтора-два спринта работы в состоянии «можем взять хоть завтра». Это эвристика, а не правило Scrum: чем стабильнее домен, тем меньше запас; чем выше неопределённость, тем меньше смысла его наращивать.

[практика] Мнемоника DEEP (Роман Пихлер, Майк Кон): бэклог должен быть Detailed appropriately — детализирован соразмерно близости, Estimated — оценён, Emergent — развивающийся, Prioritized — упорядоченный. Удобная проверка состояния бэклога на ретроспективе.

Отдельно про переход «не завершён → возвращается». [SG] Незавершённый элемент не «переносится в следующий спринт» автоматически: он возвращается в Product Backlog, и Product Owner заново решает его порядок. На практике это часто один и тот же результат, но разница принципиальная — решение принимает PO, а не инерция.

Уточнение бэклога: деятельность, а не встреча

Здесь начинается самая частая путаница. Половина команд проводит «груминг по четвергам в 15:00» и считает это событием Scrum. Половина не проводит ничего и каждое планирование тонет.

[SG] Уточнение — постоянная деятельность. Форма не задана. [практика] Работающие формы:

• Регулярная сессия 45–60 минут раз в неделю. Самая распространённая. Плюс — предсказуемость, все в одном контексте. Минус — легко превращается в ритуал, где обсуждают то, что оказалось наверху случайно.
• Уточнение «тройками» (Three Amigos). Product Owner, разработчик и тестировщик разбирают один элемент за 20–30 минут, потом результат приносят команде. Отлично экономит время, требует зрелости.
• По требованию. Как только элемент поднимается выше линии, кто-то из разработчиков вместе с PO приводит его в порядок. Работает в командах, привыкших к вытягиванию.
• Внутри планирования. Возможно только если бэклог уже в хорошем состоянии и уточнение сводится к последним вопросам.

[антипаттерн] Уточнение как приёмка требований. Product Owner приносит готовое ТЗ, зачитывает, спрашивает «вопросы есть?», получает молчание, ставит галочку. Это не уточнение, а передача документа. Признак: разработчики не задают вопросов. Отсутствие вопросов у команды к новой функциональности означает не ясность, а отсутствие вовлечённости.

[антипаттерн] Уточнение как оценочная сессия. Встреча существует, чтобы проставить числа. Обсуждение смысла считается потерей времени. Через месяц команда обнаруживает, что оценивает то, чего не понимает.

[антипаттерн] Уточнение без разработчиков. «Аналитики сначала подготовят, потом покажут». Гарантирует, что реализационные ограничения всплывут в середине спринта.

Что делает Scrum-мастер. Он не ведёт уточнение по должности и тем более не пишет истории за PO. Его работа — сделать так, чтобы дисфункция стала видимой. Конкретно:

• принести на ретроспективу цифру: сколько минут планирования ушло на выяснение смысла задач;
• показать корреляцию между «сколько элементов вернулись незавершёнными» и «сколько из них были уточнены заранее»;
• предложить эксперимент («две недели пробуем формат троек»), а не приказать формат;
• защищать таймбокс планирования: если событие срывается из-за неготовности бэклога, нельзя лечить это удлинением встречи, иначе проблема станет невидимой.

Декомпозиция: вертикальные срезы вместо слоёв

Самая частая техническая ошибка при разбиении — резать по архитектурным слоям. «Сначала база, потом API, потом фронт». Каждый кусок понятен инженерно и бесполезен для пользователя.

Правило проверки одно: если мы сделаем только этот элемент и остановимся — кому-то станет лучше? Если нет, это не элемент бэклога, а задача внутри Sprint Backlog. [SG] Разница важна: Product Backlog содержит то, что улучшает продукт; план работ по выбранным элементам — часть Sprint Backlog и принадлежит разработчикам.

Практические паттерны разбиения

[практика] SPIDR — мнемоника Майка Кона, пять способов разрезать крупную историю:

[практика] Дополнительные приёмы, из каталога Ричарда Лоуренса «Patterns for Splitting User Stories»:

• По шагам рабочего процесса — разбить длинную цепочку и сделать сначала критичный шаг, остальные временно вручную.
• По операциям CRUD — «создать» ценно само по себе, «редактировать» и «удалить» отдельно.
• По усилию — сделать простой вариант, узнать реальную сложность, потом решать про сложный.
• Отложить нефункциональные требования — сначала работает, потом работает за 200 мс. Осторожно: это не про отказ от качества и не про откладывание Definition of Done.

[практика] Elephant Carpaccio. Упражнение Алистера Кокбёрна: взять функциональность и нарезать её на 15–20 кусочков, каждый из которых поставляется за 15–40 минут и приносит хоть каплю пользы. Ломает у команды убеждение «мельче нельзя». Описание — на сайте Кокбёрна.

[антипаттерн] Разбиение по исполнителям. «Задача фронтендера», «задача бэкендера», «задача тестировщика». Формально мельче, фактически ни один кусок не является инкрементом, а команда перестаёт быть кросс-функциональной.

[антипаттерн] Разбиение по фазам. «Аналитика», «разработка», «тестирование» как отдельные элементы бэклога — это водопад, аккуратно разложенный по спринтам. Подробнее об этом в статье Антипаттерны Scrum.

Пример разбора: было и стало

Крупный элемент: «Личный кабинет клиента».

Это тема, а не элемент бэклога: неоценим, непоставляем, ничего не говорит о пользе. Разбираем через вопросы — какую проблему клиента решаем и что он делает сегодня вместо этого?

Выясняется: клиенты звонят в поддержку, чтобы узнать статус заказа (62% обращений) и скачать счёт (18%). Тогда:

1. Страница со статусом одного заказа по прямой ссылке из письма — без авторизации, без списка. Снимает большую часть обращений. Один спринт, возможно, половину.
2. Скачивание счёта по той же ссылке.
3. Вход по одноразовому коду и список последних заказов.
4. Полноценная авторизация с паролем, профиль, история.

Пункт 1 сам по себе снижает нагрузку на поддержку и даёт замер: правда ли дело было в статусе. Классическая ошибка — начать с пункта 4, потому что «без авторизации всё равно ничего не сделаешь». Как видно, сделать можно, и именно этот кусок несёт большую часть пользы.

Пользовательские истории: чего в Scrum нет, но что почти все используют

[SG] Формат элементов Product Backlog не задан. Ни слова про «Как <роль>, я хочу <действие>, чтобы <польза>». Элементом может быть строчка, макет, дефект, эксперимент, ссылка на исследование.

[практика] Формат истории пришёл из Extreme Programming; каноническое изложение — книга Майка Кона «User Stories Applied» (2004). Его ценность не в шаблоне, а в трёх вещах, которые Рон Джеффрис назвал «3 C»:

• Card — карточка. Намеренно маленькая: на ней физически не помещается спецификация. Это напоминание о разговоре, а не сам разговор.
• Conversation — разговор. Основной носитель требований. Именно здесь передаётся контекст, который невозможно записать.
• Confirmation — подтверждение. Критерии приёмки: как мы вместе поймём, что сделано правильно.

Забывают обычно про C номер два. Тогда история превращается в мини-ТЗ, только с неудобным синтаксисом, и получается худшее из двух миров: детальности документа нет, а разговора уже не будет.

[практика] INVEST — критерии хорошей истории, предложенные Биллом Вейком (оригинал):

[практика] Критерии приёмки. Лучше всего работают как конкретные примеры, а не как список свойств. Сравните: «система должна корректно обрабатывать ошибки оплаты» против явных сценариев.

Функционал: Оплата заказа картой

  Сценарий: Банк отклонил платёж из-за недостатка средств
    Дано заказ на 4 500 рублей в статусе "ожидает оплаты"
    Когда клиент оплачивает картой с балансом 1 000 рублей
    Тогда заказ остаётся в статусе "ожидает оплаты"
    И клиент видит сообщение "недостаточно средств, попробуйте другую карту"
    И повторная попытка оплаты доступна сразу

  Сценарий: Шлюз не ответил за 30 секунд
    Дано заказ на 4 500 рублей в статусе "ожидает оплаты"
    Когда платёжный шлюз не отвечает 30 секунд
    Тогда заказ переходит в статус "оплата уточняется"
    И запускается сверка со шлюзом через 5 минут
    И клиенту не предлагается оплатить повторно

Второй сценарий — тот самый случай, ради которого пишут примеры. Про него почти всегда забывают на словах, и он всплывает в проде. Подход подробно разобран у Гойко Аджича в «Specification by Example».

[практика] Job Stories — альтернатива от команды Intercom для случаев, когда «роль» ничего не объясняет: «Когда <ситуация>, я хочу <мотив>, чтобы <результат>». Фокус на контексте, а не на персоне. Полезно в B2B и в инфраструктурных продуктах.

[практика] Story Mapping — Джефф Паттон, «User Story Mapping». Двумерная карта: по горизонтали — шаги пользовательского пути, по вертикали — глубина проработки. Линейный бэклог теряет структуру пути; карта её возвращает и позволяет резать релизы горизонтальными полосами, каждая из которых остаётся связным сценарием.

[антипаттерн] Шаблон ради шаблона. «Как разработчик, я хочу обновить версию библиотеки, чтобы обновить версию библиотеки». Если польза не формулируется — не насилуйте формат. Напишите как есть и обсудите ценность отдельно.

Оценка: кто, зачем и насколько всерьёз

Оценка — тема, где сходятся половина антипаттернов Scrum и заметная доля вопросов PSM I.

[SG] Три факта, которые нужно знать дословно:

1. Оценивают разработчики — те, кто будет делать работу. Не Product Owner, не Scrum-мастер, не менеджер.
2. Product Owner может влиять на оценку, помогая понять компромиссы — но не изменять её.
3. Guide говорит о размере (size), а не о часах, и не предписывает никакой шкалы.

Всё остальное — практика.

Почему относительная оценка, а не часы

Человек плохо оценивает абсолютные величины и заметно лучше — сравнительные. Спросите, сколько минут займёт дорога до вокзала — ошибётесь. Спросите, дальше ли вокзал, чем аптека — ответите точно. Story points эксплуатируют именно это: элемент оценивают не в единицах времени, а относительно другого элемента, взятого за эталон.

Второй мотив — социальный. Оценка в часах моментально превращается в обязательство и в инструмент давления: «ты сказал восемь часов, где результат?» Абстрактная единица хуже поддаётся такому переводу. Правда, ненадолго: организации быстро учатся делить story points на часы, и тогда весь смысл теряется.

[практика] Шкалы. Модифицированный ряд Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100) — растущие интервалы отражают растущую неопределённость: разница между 1 и 2 осмысленна, между 20 и 21 — иллюзорна. Размеры футболок (S, M, L, XL) — то же самое, но сильнее сопротивляются превращению в часы.

[практика] Планирование покером. Одновременное вскрытие оценок — защита от эффекта якоря: если первым назовёт число самый авторитетный участник, остальные подстроятся, и вы получите одно мнение вместо шести. Эффект якорения хорошо описан у Канемана в «Думай медленно… решай быстро»; в оценке проектов он работает беспощадно.

[практика] Ключевая ценность оценки — не число, а разговор. Разброс «2 против 13» означает, что участники обсуждают разные задачи. Обнаружение этого расхождения ценнее любого итогового значения. Команды, которые научились быстро расходиться и сходиться, в какой-то момент замечают, что число им уже не нужно.

Альтернатива: считать элементы, а не очки

[практика] Если команда научилась резать элементы на сопоставимо мелкие куски, прогноз по количеству элементов оказывается не хуже прогноза по очкам — и дешевле. Это ядро аргумента #NoEstimates и вероятностного прогнозирования по throughput, подробно разобранного Дэниелом Ваканти в «Actionable Agile Metrics for Predictability».

Практический критерий перехода: если 80% элементов у вас имеют размер 1–3 очка, очки перестали нести информацию. Считайте штуки и стройте прогноз по историческому распределению, а не по среднему. О метриках и их искажениях — статья Эмпиризм и метрики, а о технике оценки в более широком контексте управления проектами — Оценка и планирование.

Антипаттерны оценки

[антипаттерн] Оценка как обязательство. Менеджмент трактует сумму очков в спринте как обещание. Следствие: команда закладывает запас, очки инфлируют, прогноз ухудшается, доверие падает. Scrum-мастер здесь работает не с командой, а с менеджментом: объясняет разницу между прогнозом и обязательством и напоминает, что [SG] единственное обязательство спринта — цель спринта, а не набор элементов.

[антипаттерн] Сравнение velocity между командами. Очки — локальная валюта одной команды. Межкомандное сравнение эквивалентно сравнению цен в разных валютах без курса. Обычный результат — инфляция очков во всех командах сразу.

[антипаттерн] Оценка задач в часах внутри спринта, спущенная сверху. [SG] Sprint Backlog принадлежит разработчикам. Требование от менеджера дробить работу на часовые задачи и отчитываться по ним — вторжение в чужую ответственность.

[антипаттерн] Оценка Product Owner’ом «для скорости». «Я примерно прикинул, тут на день». С этого момента разработчики оценивают не задачу, а ожидание PO.

[антипаттерн] Definition of Ready как ворота. [практика] Список условий, без которых элемент нельзя взять в спринт. Иногда полезен как ориентир — но регулярно превращается в бюрократический шлагбаум и в контракт между PO и командой: «пока не заполнены все поля, мы не начинаем». В Scrum Guide такого понятия нет; на экзамене ответ «нужен Definition of Ready» почти всегда неверный.

Сценарии из жизни: как поступает Scrum-мастер

Сценарий 1. Планирование срывает таймбокс третий спринт подряд. Product Owner приносит элементы, которые команда видит впервые. Обсуждение съедает три часа из четырёх.

Что не делать: удлинять планирование, писать истории за PO, запрещать брать неуточнённое.

Что делать: сделать проблему видимой. Замерить долю времени планирования, ушедшую на выяснение смысла, и принести цифру на ретроспективу — не как обвинение, а как факт. Дальше вопрос команде: «Что мы можем изменить в своей работе, чтобы этого не происходило?» Если выяснится, что у PO физически нет времени — это уже организационное препятствие, и разговор идёт с менеджментом: либо часть работы делегируется команде [SG: PO вправе делегировать, оставаясь подотчётным], либо у PO снимают другие обязанности.

Сценарий 2. Product Owner требует, чтобы команда «уложилась в оценку». «Вы оценили в 5, а делаете уже неделю».

Что делать: разделить два разговора. Первый — про механику: оценка это прогноз, не контракт; [SG] оценивают разработчики, PO влияет через компромиссы, а не через давление. Второй — про реальную потребность PO: обычно за требованием стоит внешнее обязательство перед клиентом, и настоящая работа Scrum-мастера — помочь PO управлять этим обязательством через объём (что можно выкинуть), а не через нажим на людей.

Сценарий 3. Бэклог из 800 элементов, половина старше года. Никто не помнит, что значит половина строк.

Что делать: признать, что незакрытый бэклог такого размера — не актив, а долг. Он снижает прозрачность: найти важное невозможно. Предложить PO решение через порядок, а не через удаление: всё, что ниже определённой границы и не двигалось год, архивируется. Возражение «вдруг понадобится» лечится фактом: если элемент действительно понадобится, он появится снова, и в лучшей формулировке. [SG] Решение принимает PO — Scrum-мастер только показывает цену беспорядка.

Сценарий 4. Разработчики отказываются оценивать: «мы не можем знать». Обычно за этим стоит либо прошлый опыт наказания за промах, либо действительно высокая неопределённость.

Что делать: сначала выяснить, какая из двух причин. Если наказание — работа с менеджментом и с безопасностью среды, тема статьи Коучинг команды, конфликты и сопротивление. Если неопределённость — предложить спайк с таймбоксом: не «оцените неизвестное», а «потратьте два дня и вернитесь с ответом, сколько это стоит».

Сценарий 5. Менеджмент просит квартальный план по бэклогу. Требование законное: у бизнеса есть обязательства перед рынком.

Что делать: не отвечать «Scrum так не работает». Показать, что можно дать: вероятностный прогноз на основе исторической пропускной способности («с вероятностью 85% эти 12 элементов будут сделаны за 6 спринтов») вместо точной даты. Явно проговорить допущение: прогноз действителен, пока не меняется состав команды и порядок бэклога.

Вопросы в формате PSM I

Вопрос 1. Кто отвечает за оценку размера элементов Product Backlog?

• A. Product Owner, поскольку он отвечает за бэклог
• B. Scrum-мастер, поскольку он отвечает за процесс
• C. Разработчики, которые будут выполнять работу
• D. Наиболее опытный разработчик команды

Вопрос 2. Когда проводится уточнение Product Backlog?

• A. На отдельном событии в середине спринта
• B. Это постоянная деятельность в течение спринта; Scrum не предписывает форму
• C. На планировании спринта, до выбора элементов
• D. На обзоре спринта, вместе со стейкхолдерами

Вопрос 3. Сколько ёмкости команды Scrum Guide предписывает выделять на уточнение бэклога?

• A. Не более 10%
• B. От 5% до 10%
• C. Столько, сколько решит Product Owner
• D. Scrum Guide не задаёт норму

Вопрос 4. Элемент Product Backlog, выбранный в спринт, не был завершён к концу спринта. Что происходит?

• A. Спринт продлевается до завершения элемента
• B. Элемент автоматически переносится в следующий спринт
• C. Элемент возвращается в Product Backlog, Product Owner заново определяет его порядок
• D. Элемент считается сделанным частично, засчитывается пропорционально

Вопрос 5. Product Owner отсутствует на сессии уточнения. Разработчики уточняют элементы сами. Верно ли это?

• A. Нет, без Product Owner уточнение невозможно
• B. Нет, Scrum-мастер должен заменить Product Owner
• C. Да, Product Owner может делегировать работу по уточнению, оставаясь подотчётным
• D. Да, но результат недействителен до утверждения Product Owner

Вопрос 6. Какое из утверждений о Product Backlog верно?

• A. Product Backlog содержит только пользовательские истории
• B. Product Backlog является единственным источником работы Scrum-команды
• C. Product Backlog замораживается на время спринта
• D. Порядок элементов Product Backlog определяет команда разработчиков

Типичные ошибки начинающего Scrum-мастера

• Стать аналитиком. Самый распространённый дрейф роли: Scrum-мастер начинает писать истории, потому что «PO не успевает, а работа стоит». Через квартал это уже обязанность, дисфункция стала невидимой, а прозрачность потеряна.
• Ввести Definition of Ready как формальные ворота. Помогает один-два спринта, потом превращается в контракт между PO и командой и в способ отказываться от работы.
• Бороться за формат «Как <роль>, я хочу…». Формат — средство. Требование заполнять шаблон при пустом разговоре даёт бюрократию без смысла.
• Пытаться уточнить весь бэклог. Детализация дальних элементов — заранее списанные потери.
• Молчать про давление на оценки. Если менеджмент требует «уложиться в очки», а Scrum-мастер не поднимает вопрос, команда защищается инфляцией оценок, и эмпиризм заканчивается.
• Оценивать вместе с командой. Scrum-мастер не разработчик в этой команде и не выполняет работу — его число там лишнее и искажает картину.

Мини-итог

• [SG] Product Backlog — развивающийся упорядоченный список, единственный источник работы; его обязательство — цель продукта. За формулировки, порядок и прозрачность отвечает Product Owner, который вправе делегировать исполнение, оставаясь подотчётным.
• [SG] Уточнение — постоянная деятельность, а не событие; нормы в процентах в редакции 2020 нет. Критерий готовности элемента — помещаемость в спринт с доведением до Definition of Done.
• [SG] Оценивают разработчики; Product Owner влияет через компромиссы по объёму, а не через давление на числа.
• [практика] Бэклог — градиент детализации: мелко и точно сверху, крупно и грубо снизу; запас над линией готовности порядка полутора-двух спринтов.
• [практика] Декомпозиция — вертикальными срезами сквозь все слои. Проверка: «сделаем только это и остановимся — кому-то станет лучше?». Инструменты: SPIDR, каталог Лоуренса, Elephant Carpaccio.
• [практика] Пользовательские истории ценны не шаблоном, а тремя C: карточка, разговор, подтверждение. INVEST — набор проверок, а не закон.
• [практика] Ценность оценки — в обнаружении расхождений в понимании, а не в числе. Когда элементы стали одинаково мелкими, считать штуки дешевле и точнее.
• [антипаттерн] Оценка как обязательство, сравнение velocity между командами, Definition of Ready как шлагбаум, уточнение без разработчиков, разбиение по слоям и по исполнителям.

Что дальше

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

Источники

• The Scrum Guide — разделы «Product Backlog», «Commitment: Product Goal», «Sprint Planning». Единственный источник истины для PSM I
• Mike Cohn, «User Stories Applied: For Agile Software Development», Addison-Wesley, 2004
• Bill Wake, «INVEST in Good Stories, and SMART Tasks», 2003
• Richard Lawrence, «Patterns for Splitting User Stories» — самый полный практический каталог приёмов разбиения
• Jeff Patton, «User Story Mapping», O’Reilly, 2014
• Ron Jeffries, «Essential XP: Card, Conversation, Confirmation» и «Story Points Revisited» — в том числе публичное сожаление автора о том, во что превратились story points
• Gojko Adzic, «Specification by Example», Manning, 2011
• Alistair Cockburn, «Elephant Carpaccio» — упражнение на предельно мелкую нарезку
• Daniel Vacanti, «Actionable Agile Metrics for Predictability», 2015 — вероятностное прогнозирование вместо оценок
• Roman Pichler, «Agile Product Management with Scrum» — источник мнемоники DEEP