Артефакты и обязательства: цель продукта, цель спринта, Definition of Done

Спросите у команды, которая полгода «делает Scrum»: «Какая у вас цель этого спринта?» В половине случаев вы услышите пересказ доски: «Ну, мы делаем вот эти восемь тикетов». В четверти — честное «а мы её не формулируем, у нас просто приоритетный бэклог». И только в оставшейся четверти вам ответят одним предложением, из которого понятно, зачем нужен весь спринт целиком.

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

Эта статья — про артефакты Scrum и про то новое, что Scrum Guide 2020 к ним добавил: обязательства (commitments). Мы разберём каждую пару «артефакт + обязательство» по одной схеме: что буквально написано в Scrum Guide → какую задачу это решает → что ломается, если убрать → как это выглядит на практике и как извращают.

Про сами события, внутри которых артефакты рождаются и осматриваются, — в статье События Scrum. Про то, кто за что отвечает, — в Три ответственности.

Зачем вообще нужны артефакты: прозрачность как предусловие

Scrum стоит на эмпирическом контроле процесса: прозрачность → инспекция → адаптация. Порядок здесь не декоративный, а причинно-следственный. Инспекция непрозрачного даёт ложные выводы; адаптация по ложным выводам делает хуже, чем бездействие.

Scrum Guide формулирует это прямо:

Артефакты Scrum представляют работу или ценность. Они спроектированы так, чтобы максимизировать прозрачность ключевой информации. Таким образом, каждый, кто инспектирует их, имеет одинаковую основу для адаптации.

И дальше — ключевое предложение, которое в редакции 2020 года изменило всю конструкцию:

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

Вдумайтесь: обязательство — это точка отсчёта для измерения прогресса. Product Backlog сам по себе не говорит, движемся мы куда-то или просто перебираем задачи. Он становится осмысленным только относительно Product Goal. Sprint Backlog без Sprint Goal — это канбан-доска на две недели. Инкремент без Definition of Done — это набор веток, про которые каждый думает своё.

Так написано в Scrum Guide. Артефактов ровно три: Product Backlog, Sprint Backlog, Increment. Обязательств ровно три: Product Goal, Sprint Goal, Definition of Done. Burndown-чарт, доска задач, roadmap, RACI-матрица — не артефакты Scrum. Это полезные практики, но на экзамене PSM I ответ «burndown — артефакт Scrum» всегда неверный.

Product Backlog и Product Goal

Что говорит Scrum Guide

Product Backlog — это эмерджентный упорядоченный список того, что нужно для улучшения продукта. Он единственный источник работы, которую берёт на себя Scrum-команда. Обратите внимание на три слова:

• эмерджентный (emergent) — не составляется один раз в начале, а постоянно возникает и меняется;
• упорядоченный (ordered), а не «приоритизированный» — это отдельный список, где есть первый, второй, третий элемент, а не набор корзинок «High / Medium / Low»;
• единственный источник работы — если разработчик что-то делает, это должно быть отражено в бэклоге.

Product Goal — обязательство Product Backlog. Scrum Guide: «Product Goal описывает будущее состояние продукта, которое может служить целью для планирования Scrum-команды. Product Goal находится в Product Backlog. Остальной Product Backlog возникает, чтобы определить, что реализует Product Goal».

За формулирование и явное донесение Product Goal отвечает Product Owner. И ещё одно правило, которое любят на экзамене: Scrum-команда должна выполнить (или отказаться от) один Product Goal, прежде чем взяться за следующий.

Какую задачу решает Product Goal

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

Product Goal даёт ответ на вопрос «во что превратится продукт», который стоит между стратегией компании и содержимым спринта.

Хорошие формулировки — про состояние продукта, а не про объём работы:

• «Самозапись на приём работает без звонка в колл-центр для всех амбулаторных услуг клиники» — состояние, проверяемое.
• «Онбординг нового мерчанта занимает меньше суток без участия менеджера» — состояние, измеримое.

Плохие формулировки:

• «Реализовать 40 задач из эпика “Личный кабинет”» — это объём работы, а не состояние.
• «Стать лидером рынка» — это стратегия компании, из неё не выводится содержимое бэклога.
• «Улучшить UX» — не проверяется, значит не даёт основы для инспекции.

Что ломается без Product Goal

• Бэклог превращается в свалку заявок. Нет критерия, по которому что-то можно выбросить: любая идея «вроде полезная».
• Порядок бэклога спорят каждый спринт заново. Без общей цели приоритет — это результат политического торга, а не логики.
• Sprint Review вырождается в демо. Стейкхолдерам показывают, что успели, но не могут ответить, приблизило ли это к чему-нибудь.
• Инкремент теряет смысл. Scrum Guide называет инкремент «конкретной ступенькой к Product Goal». Без цели ступенька ведёт неизвестно куда.

Практика: где живёт Product Goal и на какой срок

Так делают на практике. Горизонт Product Goal обычно квартал–полгода, реже год. Формально Scrum Guide срок не задаёт. Работающая эвристика: цель должна быть достаточно далёкой, чтобы её нельзя было закрыть за один спринт, и достаточно близкой, чтобы команда верила в её достижимость. Если Product Goal не меняется полтора года — скорее всего, это не цель, а миссия.

Так делать не стоит. Заводить «цель продукта» и «цель релиза» и «цель квартала» и OKR — все одновременно, в разных инструментах. Множественность целей = отсутствие цели. Если в компании уже есть OKR, свяжите Product Goal с одним конкретным Key Result, а не заводите параллельный контур. Про то, как OKR и продуктовые цели устроены на уровне продукта, есть отдельный разбор в Стратегия и роадмап.

Sprint Backlog и Sprint Goal

Три части одного артефакта

Scrum Guide устроил Sprint Backlog необычно — как композицию трёх вещей, отвечающих на три вопроса:

И следом важнейшая фраза: «Sprint Backlog — это план, созданный разработчиками и для разработчиков». Это не отчёт для менеджера и не обязательство перед стейкхолдерами. Менять его в течение спринта могут только Developers.

Sprint Backlog должен быть «высоковидимой картиной работы в реальном времени» — то есть обновляться по мере узнавания нового, минимум ежедневно на Daily Scrum, а не «раз в спринт при закрытии».

Sprint Goal: главный механизм, которым почти никто не пользуется

Scrum Guide: «Sprint Goal — это единственная цель спринта. Хотя Sprint Goal является обязательством разработчиков, он даёт гибкость в отношении точного объёма работы, необходимой для его достижения».

Здесь спрятан весь смысл. Разберём по частям.

«Единственная». Не «цели спринта», а одна. Если у вас три цели, у вас нет цели: при конфликте приоритетов внутри спринта нечем разрешить спор.

«Обязательство разработчиков». Не Product Owner ставит цель как задание сверху. Цель формулируется совместно на планировании (PO приносит контекст — почему этот спринт ценен), но берут её на себя те, кто будет делать.

«Даёт гибкость в отношении объёма работы». Вот это и есть рабочий механизм. Scrum Guide прямо описывает сценарий: «Если работа оказывается иной, чем ожидалось, они сотрудничают с Product Owner, чтобы обсудить объём Sprint Backlog в рамках спринта, не влияя на Sprint Goal».

То есть контракт спринта — это не список задач, а цель. Задачи внутри спринта — переменная. Это ровно противоположно тому, как спринт понимают в большинстве компаний, где «спринт сорван» означает «не все тикеты в колонке Done».

Так делать не стоит. Менять Sprint Goal в середине спринта, чтобы «спринт всё равно засчитался». Если цель стала неактуальной — это сигнал, а не неудобство. Scrum Guide допускает только одно действие: отмену спринта, и право на неё есть исключительно у Product Owner. Отмена спринта — редчайшее событие; за карьеру Scrum-мастера их бывает единицы.

Как формулировать Sprint Goal

Плохо: «Сделать задачи PAY-101, PAY-104, PAY-118». Это перечисление, а не цель — из него нельзя вывести, чем можно пожертвовать.

Хорошо: «Пользователь может оплатить заказ картой и получить чек — на тестовом контуре, для одного банка-эквайера». Из такой формулировки сразу видно, что «поддержка второго эквайера» — не часть цели и её можно вернуть в бэклог, а «получение чека» — часть, и её выкинуть нельзя.

Рабочий шаблон: «Чтобы <кто> смог <что>, мы <что делаем>» или проще — одно предложение, которое можно сказать стейкхолдеру, не открывая доску.

Проверки качества цели:

1. Можно ли по ней понять, что спринт удался, не глядя на количество закрытых тикетов?
2. Есть ли в спринте элементы, которые к цели не относятся? Если да — почему они там? (Иногда законно: техдолг, поддержка. Но их не должно быть большинство.)
3. Можно ли на её основе вести переговоры о скоупе? Если из цели не следует, что важно, а что нет, — цель бесполезна.

Что ломается без Sprint Goal

• Спринт становится неделимым. Любое «не успеваем» = провал, потому что нечего сокращать без потери лица.
• Daily Scrum вырождается в статус-митинг. Scrum Guide говорит, что цель дейли — инспектировать прогресс к Sprint Goal. Нет цели — нечего инспектировать, остаётся «кто чем занят».
• Команда не приоритизирует внутри спринта. Восемь задач берут восемь человек параллельно, к концу спринта восемь задач в статусе «почти готово».
• Sprint Review не про ценность. Показывают набор фич, а не результат.

Increment и Definition of Done

Что такое инкремент

Scrum Guide: «Инкремент — это конкретная ступенька к Product Goal. Каждый инкремент аддитивен ко всем предыдущим инкрементам и тщательно проверен, что гарантирует совместную работу всех инкрементов. Чтобы приносить ценность, инкремент должен быть пригоден к использованию (usable)».

Три нюанса, на которых на экзамене ловят:

1. Инкрементов в спринте может быть несколько. «Один спринт = один инкремент» — распространённое, но неверное представление. Инкремент рождается в момент, когда элемент бэклога начинает соответствовать Definition of Done.
2. Инкремент можно отдать пользователям в любой момент. Scrum Guide специально уточняет: «Sprint Review никогда не следует считать воротами для выпуска ценности». Релиз не привязан к концу спринта; это решение Product Owner.
3. Инкремент — не обязательно релиз. Он должен быть пригоден к использованию, то есть быть в таком состоянии, что решение о выпуске — чисто бизнесовое, а не «надо ещё две недели стабилизировать».

Definition of Done: определение и правила владения

Definition of Done — это формальное описание состояния инкремента, когда он соответствует требованиям качества, необходимым для продукта.

И дальше — самое жёсткое правило во всём Scrum Guide:

В момент, когда элемент Product Backlog начинает соответствовать Definition of Done, рождается инкремент. Если элемент Product Backlog не соответствует Definition of Done, он не может быть выпущен или даже представлен на Sprint Review. Вместо этого он возвращается в Product Backlog для будущего рассмотрения.

Никакого «сделано на 80%». Либо соответствует, либо возвращается в бэклог.

Правила владения, которые постоянно путают:

Обратите внимание: DoD создаёт вся Scrum-команда, а не Scrum Master и не Product Owner единолично. Scrum Master помогает команде прийти к нему и помогает организации понять, зачем он нужен, — но не пишет его за команду.

DoD против критериев приёмки: различие, которое стоит проговорить вслух

Это самая частая путаница на практике и один из любимых сюжетов на экзамене.

Пример. Элемент «Пользователь может восстановить пароль по email».

• Acceptance criteria: письмо приходит в течение 60 секунд; ссылка живёт 30 минут; повторный запрос инвалидирует прошлую ссылку.
• Definition of Done: код прошёл ревью; юнит- и интеграционные тесты зелёные; развёрнуто на staging из main; нет открытых блокеров; добавлены метрики и логи; обновлены релиз-ноты.

Элемент считается готовым, только когда выполнено и то и другое. Про то, как формулировать критерии приёмки и не превращать их в спецификацию, — в следующей статье трека, Работа с бэклогом, а инженерная сторона (какие именно проверки имеет смысл вносить в DoD) разобрана в треке тестирования, например Тесты в CI.

Как строить DoD, который работает

Принцип: DoD описывает то, что команда реально делает и может проверить. Не мечту, не стандарт из книги, не требования отдела качества.

Шаги, которые хорошо работают на практике:

1. Инвентаризация текущего. Соберите команду и составьте список всего, что фактически происходит между «код написан» и «пользователь пользуется». Обычно вылезает 15–25 шагов, половину из которых делает один человек и никто больше про них не знает.
2. Разделите на три колонки: «делаем всегда» → это и есть текущий DoD; «делаем иногда» → кандидаты на ужесточение; «не делаем, но надо» → бэклог улучшений.
3. Зафиксируйте минимальную честную версию. Слабый, но правдивый DoD полезнее сильного, но фиктивного: он даёт настоящую прозрачность.
4. Усиливайте на ретроспективах. Раз в несколько спринтов переносите один пункт из «иногда» в «всегда». Это конкретная, наблюдаемая форма kaizen.

Признаки, что DoD написан для галочки:

• В нём есть пункты, которые никто не может проверить («код качественный», «архитектура соответствует стандартам»).
• Никто не помнит, где он лежит.
• За полгода он не менялся ни разу, хотя процессы менялись.
• Команда регулярно показывает на обзоре то, что ему не соответствует, и это никого не смущает.

Undone work: главная опасность слабого DoD

Если DoD не включает что-то, что всё равно придётся сделать перед релизом (нагрузочное тестирование, безопасность, миграции, документация), эта работа никуда не исчезает — она накапливается невидимо. Команда рапортует стабильную скорость, инкремент выглядит растущим, а перед релизом внезапно нужен «спринт стабилизации».

Это и есть скрытый водопад внутри Scrum: фазы никуда не делись, они просто спрятались в конце. Разбор этого и родственных антипаттернов — в Антипаттерны Scrum, а про то, как метрики маскируют проблему, — в Эмпиризм и метрики.

Definition of Ready — осторожно

Так делать не стоит (обычно). «Definition of Ready» в Scrum Guide нет. На практике команды вводят его, чтобы не брать в спринт непонятные элементы, и в умеренной форме это разумная договорённость при уточнении бэклога.

Опасность в том, что DoR легко превращается в шлюз между Product Owner и Developers: «мы не возьмём это в спринт, пока ты не заполнишь все поля». Это восстанавливает передачу работы через забор — ровно то, что Scrum пытается устранить. Если у вас появился DoR с восемью обязательными полями и процедурой согласования, вы построили мини-водопад на входе в спринт.

Практический критерий: DoR как эвристика для разговора — нормально. DoR как формальные ворота с отказами — антипаттерн.

Разбор сценариев: что делает Scrum-мастер

Сценарий 1. «Мы почти закончили» на обзоре спринта

Ситуация. На Sprint Review разработчик показывает фичу и говорит: «Всё работает, только автотесты ещё не написали и на staging не выкатили, но это мелочь, доделаем в понедельник». Product Owner кивает и записывает элемент как закрытый.

Что здесь не так. Автотесты и деплой в DoD. Значит, элемент не готов и не должен был показываться как готовый. Заявленная скорость команды завышена; накапливается undone work.

Что делать Scrum-мастеру. Не устраивать публичный разбор на обзоре — это не место для процессных споров при стейкхолдерах. Задать нейтральный вопрос: «Правильно ли я понимаю, что по нашему DoD этот элемент ещё не готов?» — и вынести тему на ретроспективу. На ретро исследовать причину: почему элемент взяли в спринт таким объёмом, почему проверку DoD никто не делает до обзора, не является ли DoD нереалистичным.

Чего делать не надо. Запрещать, отчитывать, вводить «контроль DoD Scrum-мастером». Scrum-мастер не контролёр качества; он делает проблему видимой команде и помогает ей самой найти механизм.

Сценарий 2. Product Owner приносит срочную задачу на четвёртый день спринта

Ситуация. «Коммерческий директор просит баннер к акции, надо в этот спринт. Добавьте, пожалуйста».

Что говорит Scrum Guide. Изменять Sprint Backlog могут только Developers. Никто не может заставить команду взять работу. При этом Sprint Goal — обязательство, и добавление работы допустимо, если не ставит цель под угрозу.

Что делать Scrum-мастеру. Не решать за команду и не блокировать PO. Организовать разговор из трёх вопросов:

1. Поможет ли эта задача достижению Sprint Goal или нет?
2. Если нет — что мы уберём из спринта, чтобы цель осталась достижимой?
3. Если ни то ни другое невозможно — цель спринта устарела? Тогда решение об отмене спринта принимает Product Owner.

Системная часть. Если такое происходит каждый спринт, проблема не в конкретной задаче. Scrum-мастер выносит на ретроспективу вопрос: почему у продукта нет канала для срочной работы и почему бэклог не отражает реальность. Возможные ответы — от «нужен буфер на непредвиденное» до «этой команде подходит не Scrum, а поток» (см. Kanban и поток).

Сценарий 3. Пять команд, пять разных DoD

Ситуация. Продукт один, команд пять. У каждой свой DoD: одна пишет интеграционные тесты, другая нет; одна деплоит сама, другая передаёт релиз-инженеру.

Что говорит Scrum Guide. Если несколько Scrum-команд работают над одним продуктом, они обязаны совместно определить и соблюдать один и тот же Definition of Done. Это не рекомендация.

Что делать Scrum-мастеру. Собрать представителей всех команд и вывести общий DoD как пересечение реально выполняемого (не объединение желаемого!) — это даст честную стартовую точку. Затем сделать план усиления: раз в квартал добавляем один пункт, синхронно во всех командах. Параллельно — вскрыть, почему команды разошлись: обычно это разница в доступе к инфраструктуре, а не в дисциплине. Подробнее про многокомандные конструкции — в Масштабирование Scrum.

Сценарий 4. Sprint Goal формулирует Product Owner в одиночку

Ситуация. PO приходит на планирование с готовой целью в слайде и просит команду «набрать задач под неё».

Что не так. Формально Sprint Goal рождается в ходе планирования, а обязательство берут Developers. Односторонне назначенная цель — это задание, а не обязательство; команда не будет её защищать.

Что делать Scrum-мастеру. Не отменять подготовку PO — она полезна. Изменить формат: PO приносит контекст и предложение («вот почему следующий спринт ценен именно так»), а формулировку цели команда доводит вместе, вслух, до состояния «мы понимаем, чем можно пожертвовать». Хороший фасилитационный приём — попросить команду переформулировать цель своими словами и сверить с PO. Подробнее про приёмы — в Фасилитация.

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

1. Кто отвечает за формулирование и явное донесение Product Goal?

A. Scrum Master B. Developers C. Product Owner D. Вся Scrum-команда совместно

Верно: C. Scrum Guide в разделе про Product Owner: он отвечает за эффективное управление Product Backlog, что включает «разработку и явное донесение Product Goal». Ловушка в варианте D: команда участвует в работе с бэклогом и с целью, но ответственность (accountability) — у одного человека. В Scrum ответственности не размазываются.

2. Элемент Product Backlog взят в спринт, работа над ним сделана, но он не соответствует Definition of Done. Что происходит?

A. Он считается готовым частично, оставшаяся часть переносится в следующий спринт B. Он возвращается в Product Backlog C. Он показывается на Sprint Review как «почти готовый» D. Sprint Goal автоматически считается недостигнутым

Верно: B. Scrum Guide формулирует буквально: если элемент не соответствует DoD, он не может быть выпущен или даже представлен на Sprint Review, а возвращается в Product Backlog. Ответ A описывает распространённую практику, но она противоречит Guide: «частично готово» — это не состояние в Scrum. Ответ D неверен, потому что цель спринта может быть достигнута и без этого элемента — в том и смысл цели.

3. На середине спринта Developers понимают, что выбранный объём работы недостижим. Что им следует сделать?

A. Продлить спринт на неделю B. Сообщить об этом на Sprint Review C. Сотрудничать с Product Owner, чтобы обсудить объём Sprint Backlog, не влияя на Sprint Goal D. Попросить Scrum Master добавить людей в команду

Верно: C. Прямая цитата из раздела про Sprint Goal. Ответ A невозможен: длительность спринта фиксирована, таймбокс не продлевается. Ответ B откладывает прозрачность до конца спринта — противоположность эмпиризму. Ответ D не решает проблему (закон Брукса) и не входит в полномочия Scrum-мастера.

4. Сколько инкрементов может быть создано в течение одного спринта?

A. Ровно один B. Один на каждого разработчика C. Столько, сколько элементов удовлетворило Definition of Done D. Ни одного, если спринт был неуспешным

Верно: C. Scrum Guide: «В течение спринта может быть создано несколько инкрементов», и инкремент рождается в момент соответствия элемента DoD. Вариант A — самое частое заблуждение, потому что на обзоре сумма инкрементов показывается один раз.

5. Организация ввела корпоративный стандарт Definition of Done. Что должна делать Scrum-команда?

A. Игнорировать его, поскольку DoD принадлежит команде B. Следовать ему как минимуму, при желании ужесточая C. Заменить его собственным, если считает свой лучше D. Использовать его только для релизных спринтов

Верно: B. Scrum Guide: если DoD для инкремента является частью стандартов организации, все Scrum-команды должны следовать ему как минимуму; если не является — команда создаёт свой, подходящий продукту. Ослаблять корпоративный стандарт нельзя, усиливать — можно.

6. Кто может изменять Sprint Backlog во время спринта?

A. Product Owner, поскольку он отвечает за ценность B. Scrum Master, поскольку он отвечает за процесс C. Developers D. Любой член Scrum-команды по согласованию с менеджером

Верно: C. Sprint Backlog — план, созданный разработчиками и для разработчиков; только они его изменяют. Product Owner участвует в переговорах о скоупе, но само изменение плана — за разработчиками. Вариант B — типичная ловушка на роль Scrum-мастера как администратора.

7. Что из перечисленного НЕ является артефактом Scrum?

A. Product Backlog B. Sprint Backlog C. Sprint Burndown Chart D. Increment

Верно: C. Артефактов ровно три. Burndown, burn-up и cumulative flow упоминаются в Scrum Guide как полезные практики прогнозирования, но с оговоркой, что они «не заменяют важности эмпиризма». Такие вопросы «что не входит в список» на PSM I встречаются регулярно — списки стоит знать буквально.

Типичные ошибки Scrum-мастера в работе с артефактами

1. Владеть артефактом вместо команды. Scrum-мастер, который сам ведёт доску, сам обновляет Sprint Backlog и сам пишет DoD, снимает с команды ответственность. Артефакт перестаёт отражать реальность — он отражает представление Scrum-мастера о реальности.
2. Путать инструмент и артефакт. Jira — не Product Backlog. Product Backlog — это упорядоченный список того, что улучшит продукт; он может жить в Jira, в таблице или на стене. Когда команда обсуждает «как настроить workflow», а не «что делает продукт лучше», подмена уже произошла.
3. Делать DoD инструментом давления. «Вы не соблюдаете DoD» звучит как обвинение и вызывает сопротивление. Продуктивнее: «наш DoD говорит вот это, реальность выглядит вот так — где расхождение и что его вызывает?» Подробнее о работе с сопротивлением — в Коучинг и конфликты.
4. Защищать букву в ущерб задаче. Если команда стабильно достигает целей, поставляет работающий инкремент и улучшается, а Sprint Goal записан у неё не в тикете, а на маркерной доске, — это не проблема. Проблема — когда цели нет вообще.
5. Считать прозрачность достигнутой, потому что есть дашборд. Прозрачность — это когда все инспектирующие делают одинаковые выводы. Красивый дашборд с завышенными цифрами — прозрачность отрицательная: он даёт уверенность в ложном.

Мини-итог

• Артефактов три: Product Backlog, Sprint Backlog, Increment. Обязательств три: Product Goal, Sprint Goal, Definition of Done. Обязательство — это точка отсчёта, относительно которой измеряют прогресс.
• Product Goal задаёт направление на горизонте месяцев и делает возможным осмысленный порядок бэклога. Формулирует Product Owner. Одна цель за раз.
• Sprint Goal — единственная цель спринта и обязательство разработчиков. Именно он делает объём работы переменной, а не константой: скоуп обсуждается с PO внутри спринта, цель — нет. Отменить спринт может только Product Owner.
• Sprint Backlog = зачем + что + как. План разработчиков для разработчиков; менять его могут только они.
• Increment пригоден к использованию, аддитивен, может быть выпущен в любой момент; обзор спринта — не шлюз для релиза. Инкрементов в спринте может быть много.
• Definition of Done — граница между «работой» и «инкрементом». Не соответствует — возвращается в бэклог целиком. Организационный стандарт можно только ужесточать; несколько команд на одном продукте обязаны иметь общий DoD.
• Слабый DoD не экономит время, а превращает его в невидимый долг, который всплывает «спринтом стабилизации».

Источники

• The Scrum Guide 2020 — первоисточник, 13 страниц; читать целиком и не по пересказам.
• Scrum Guide на русском (PDF) — официальный перевод.
• Ken Schwaber, Jeff Sutherland. What’s New in the 2020 Scrum Guide — почему появились обязательства.
• Scrum.org: Definition of Done — практика формирования DoD.
• Evidence-Based Management Guide — как связывать цели с измеримой ценностью.
• Roman Pichler. Product Goals — практический разбор формулировок.
• Martin Fowler. Technical Debt — фон для понимания цены слабого DoD.

Что дальше

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

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