Обязательства Product Backlog, Sprint Backlog и Increment в Scrum

Здравствуйте! В прошлых уроках мы отделили Scrum от более широких ценностей Agile, разобрали роли Scrum Team и увидели, как события Scrum создают цикл прозрачности, инспекции и адаптации. Теперь перейдём к тому, на чём именно этот цикл держится: трём артефактам Scrum.

К концу урока вы сможете уверенно сопоставлять:

• Product Backlog с Product Goal;
• Sprint Backlog со Sprint Goal;
• Increment с Definition of Done.

Это особенно важно для TPM: в Jira, Confluence и дорожных картах легко смешать продуктовые намерения, текущий рабочий план и уже поставленный результат. Scrum сознательно разделяет их, чтобы не принимать планы за факты, а незавершённую работу — за готовую ценность.

---

Артефакт и обязательство: две части одного механизма

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

Каждому артефакту соответствует обязательство (commitment). В русском переводе Scrum Guide используется слово «приверженность»; в этой теме будем говорить «обязательство». Это не обещание фиксированного объёма к определённой дате. Это ориентир, который:

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

Соответствие нужно запомнить как целостную систему:

Артефакт	Что он показывает	Обязательство	Вопрос для инспекции
Product Backlog	Что может потребоваться для развития продукта	Product Goal	Приближают ли мы продукт к целевому состоянию?
Sprint Backlog	План работы Developers внутри текущего Sprint	Sprint Goal	Продвигаемся ли мы к цели этого Sprint?
Increment	Готовое, пригодное к использованию дополнение продукта	Definition of Done	Действительно ли результат соответствует согласованному качеству?

Обратите внимание на разные горизонты:

• Product Goal направляет развитие продукта в среднесрочной или долгосрочной перспективе.
• Sprint Goal задаёт единый фокус на один Sprint.
• Definition of Done определяет качество каждого готового фрагмента продукта независимо от Sprint.

---

Product Backlog и Product Goal: направление развития продукта

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

Product Backlog не равен первоначальному ТЗ, плану проекта или складскому списку пожеланий. Он меняется по мере появления новых знаний о пользователях, регулировании, рисках, рынке и технических ограничениях. В верхней части обычно находятся наиболее понятные и актуальные элементы, которые потенциально можно взять в ближайший Sprint. Элементы ниже могут быть крупными и намеренно неопределёнными.

Обязательство этого артефакта — Product Goal. Это описание будущего состояния продукта, к которому стремится Scrum Team. Оно отвечает на вопрос: зачем существует этот набор работ?

Например, Product Goal кредитной платформы можно сформулировать так:

Клиенты могут самостоятельно завершать заявку на автокредит и видеть понятный актуальный статус обработки без необходимости обращаться к оператору.

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

Product Backlog будет раскрываться вокруг этой цели. В нём могут появиться элементы:

• сохранение черновика заявки;
• получение статуса из скоринговой системы;
• безопасное отображение промежуточных состояний;
• журналирование смены статуса;
• обработка тайм-аутов внешнего API;
• аудит просмотра чувствительных данных.

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

Важные свойства Product Goal

1. Это одна текущая цель продукта.
   Scrum Team должна достичь Product Goal или отказаться от него, прежде чем принимать следующий. Это не означает, что продукт имеет только одну метрику или что компания не может вести несколько продуктов. Речь о фокусе конкретной Scrum Team вокруг конкретного продукта.

2. Это не обещание завершить проект.
   Product Goal задаёт целевое состояние продукта, а не фиксирует календарный срок, бюджет и полный заранее известный объём.

3. Она находится в Product Backlog, а не в отдельной презентации.
   Если цель живёт только в стратегии на Confluence, а Product Backlog упорядочен по несвязанным срочным запросам, команда теряет фокус.

4. Product Owner отвечает за эффективное управление Product Backlog.
   В том числе за развитие и явное формулирование Product Goal, прозрачность элементов и их упорядочивание. Product Owner может делегировать отдельные действия, но сохраняет эту подотчётность.

Для TPM это полезный способ проверить качество дорожной карты. Если в ней десятки инициатив, спросите: к какому Product Goal относится каждая из них? Если связи нет, это может быть полезная работа, но её приоритет нужно обсуждать явно, а не маскировать под «обязательную задачу из бэклога».

---

Sprint Backlog и Sprint Goal: рабочий план на короткий цикл

На Sprint Planning часть элементов Product Backlog отбирается для текущего Sprint. Но результат планирования — не просто список задач. Возникает Sprint Backlog, который состоит из трёх частей:

Часть Sprint Backlog	Вопрос	Пример
Sprint Goal	Почему этот Sprint ценен?	Сделать этап предварительного решения понятным клиенту
Выбранные элементы Product Backlog	Что будет сделано?	Экран статуса, API статуса, обработка неполного ответа партнёра
План поставки Increment	Как Developers предполагают это реализовать?	Декомпозиция, тесты, миграции, мониторинг, технические проверки

Таким образом, Sprint Backlog — это не копия Product Backlog и не «обязательства каждого сотрудника». Это план Developers для Developers, достаточно подробный, чтобы ежедневно инспектировать продвижение к Sprint Goal.

Обязательство Sprint Backlog — Sprint Goal, единственная цель Sprint. Она создаётся во время Sprint Planning и добавляется в Sprint Backlog.

Хорошая Sprint Goal описывает полезный результат, а не перечень разрозненных задач.

Слабая формулировка:

Сделать frontend, backend, миграцию и тесты по статусам.

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

Сильнее:

Сделать следующий шаг после предварительного решения понятным для клиента.

Эта цель создаёт пространство для профессиональных решений. Например, если в ходе Sprint выяснится, что партнёрский API возвращает статусы с задержкой, Developers могут изменить детали реализации: добавить безопасный промежуточный статус, кэширование, обработку повторного запроса или наблюдаемость интеграции. Состав и план Sprint Backlog адаптируются, но цель сохраняет фокус.

Что можно и нельзя менять в Sprint Backlog

Sprint Backlog создаётся и обновляется Developers по мере того, как они получают новые знания. Это ожидаемое поведение, а не признак плохого планирования.

Внутри Sprint могут меняться:

• декомпозиция работы;
• последовательность технических задач;
• способ реализации;
• объём выбранных элементов после обсуждения с Product Owner;
• работа, необходимая для преодоления обнаруженного технического риска.

Но Sprint Goal не следует механически переписывать при каждом изменении. Если цель действительно стала неактуальной, например из-за отмены регуляторного требования или решения партнёра прекратить интеграцию, Product Owner может отменить Sprint. Это исключительная ситуация, а не обычный способ справиться с отклонением от плана.

Для TPM отсюда следует важная граница: можно помогать сделать риски, зависимости и ограничения видимыми, но нельзя превращать Sprint Backlog в персональный план назначений, который внешняя роль ежедневно редактирует за Developers.

---

Increment и Definition of Done: что можно считать результатом

Increment — это конкретное дополнение к продукту, приближающее его к Product Goal. Оно должно быть пригодным к использованию и совместимым со всеми предыдущими Increment.

Главная ошибка — считать Increment синонимом демонстрации на Sprint Review или набором задач со статусом Done в трекере.

Increment появляется в тот момент, когда элемент Product Backlog соответствует Definition of Done, или DoD. До этого он остаётся незавершённой работой — даже если разработка кода почти закончена, а интерфейс уже можно показать на тестовом стенде.

Definition of Done — формальное описание состояния Increment, при котором он удовлетворяет требованиям качества продукта. Это обязательство Increment.

Для высоконагруженной FinTech-платформы DoD может включать, например:

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

Это не универсальный шаблон. Конкретное DoD зависит от продукта и организационных стандартов. Но оно должно быть достаточно строгим, чтобы любой участник одинаково понимал слово «готово».

Что DoD делает прозрачным

Представьте, что команда завершила разработку нового API статуса заявки, но:

• контракт с внешним банком не проверен;
• при повторной доставке события возможны дубли;
• аудит изменения статуса отсутствует;
• мониторинга ошибок интеграции нет.

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

DoD защищает команду от накопления «почти готовой» работы. Без него к концу Sprint часто возникает ложная картина: формально закрыто много задач, но продукт нельзя выпустить, поддерживать или безопасно использовать.

При этом важно разделять качество и ценность:

• соответствие DoD означает, что Increment готов по согласованному качественному стандарту;
• соответствие DoD само по себе не доказывает, что продуктовая гипотеза оказалась ценной.

Например, команда может безупречно реализовать экран нового статуса, но Sprint Review покажет, что пользователям важнее уведомление о задержке скоринга. DoD отвечает на вопрос «достаточно ли качественно сделано?», а обратная связь на Review помогает ответить на вопрос «правильную ли ценность мы создаём?».

Increment может создаваться несколько раз за Sprint и поставляться стейкхолдерам до Sprint Review. Review — это событие инспекции и адаптации, а не единственная разрешённая дата релиза.

---

Сквозная картина: от намерения к готовому дополнению продукта

Рассмотрим единый пример.

У команды есть Product Goal: клиент должен самостоятельно завершать заявку на автокредит и ясно понимать, что происходит после предварительного решения.

В Product Backlog Product Owner поддерживает упорядоченный набор возможной работы: получение статуса из партнёрского API, отображение статуса для клиента, обработка задержек, уведомления, журнал действий оператора, метрики воронки.

На Sprint Planning команда формулирует Sprint Goal: сделать понятным для клиента этап предварительного решения. Developers выбирают связанные элементы Product Backlog и создают план реализации. Всё вместе образует Sprint Backlog.

В течение Sprint оказывается, что API партнёра иногда отдаёт неполный ответ. Developers адаптируют рабочий план: добавляют обработку промежуточного состояния и техническую проверку. Это не обязательно разрушает Sprint Goal: напротив, может быть нужно для его достижения.

Когда вертикальный фрагмент функции соответствует Definition of Done — протестирован, безопасен, наблюдаем, совместим с существующим продуктом, — появляется Increment. Он может быть доступен пользователю до конца Sprint.

Эта логика не является конвейером, где каждый раз полностью завершается одна фаза и начинается другая. Product Backlog продолжает уточняться, Sprint Backlog уточняется ежедневно, а Increment может появляться несколько раз за Sprint. Но обязательства удерживают каждый уровень в правильном фокусе.

---

Типичные подмены понятий

В интервью и реальной работе полезно быстро замечать следующие анти-паттерны.

Подмена	Почему неверно	Корректное понимание
Product Backlog называют планом проекта	Он постоянно развивается и отражает потребности продукта, а не фиксированный объём проекта	Это единый, упорядоченный источник работы Scrum Team
Sprint Backlog считают обещанием выполнить все задачи любой ценой	Он основан на прогнозе и адаптируется при появлении знаний	Это план Developers для достижения Sprint Goal
Sprint Goal записывают как набор тикетов	Список не создаёт общего смысла и не помогает выбрать компромисс	Это единая ценная цель Sprint
«Готово к демо» считают Increment	Работа может не пройти тесты, проверки безопасности или интеграцию	Increment существует только при соответствии DoD
DoD считают необязательным чек-листом команды	Тогда статус Done теряет смысл и прозрачность	DoD — формальный общий стандарт качества
Review считают моментом создания Increment	Increment может быть готов и поставлен раньше	Review нужен для инспекции результата и адаптации Product Backlog

В среде с несколькими командами особенно опасна разная трактовка Done. Если одна команда считает работу готовой после merge в основную ветку, а другая — только после мониторинга и безопасного развёртывания, общий продукт получает скрытый интеграционный риск. Когда несколько Scrum Teams работают над одним продуктом, им необходимо совместно определить и соблюдать единое Definition of Done.

---

Итоги

Три артефакта Scrum показывают разные уровни реальности продукта и работы:

• Product Backlog — упорядоченный, изменяемый источник работы по развитию продукта. Его обязательство — Product Goal, целевое будущее состояние продукта.
• Sprint Backlog — текущий план Developers: цель Sprint, выбранные элементы и план их реализации. Его обязательство — Sprint Goal, единый фокус Sprint.
• Increment — пригодное к использованию и совместимое дополнение к продукту. Его обязательство — Definition of Done, общий формальный стандарт качества.

Главная практическая мысль: Product Goal помогает выбирать направление, Sprint Goal помогает принимать решения в коротком цикле, а Definition of Done не позволяет выдать незавершённую работу за готовый результат.

В следующем уроке вы научитесь формулировать сильную Sprint Goal и отбирать элементы Product Backlog так, чтобы они действительно поддерживали эту цель, а не превращали Sprint в набор несвязанных задач.