События Scrum: спринт, планирование, дейли, обзор, ретроспектива

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

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

В этой статье мы разберём каждое событие через один и тот же вопрос: какую задачу оно решает и что конкретно ломается, если его убрать. Такая рамка нужна и для работы, и для экзамена: половина вопросов PSM I проверяет не знание таймбокса, а понимание назначения события.

Предыдущие статьи трека дали фундамент: https://courses.digitable.life/post/scrum-master/01-agile-values/ объясняет ценности, https://courses.digitable.life/post/scrum-master/02-scrum-guide/ — устройство самого Guide, https://courses.digitable.life/post/scrum-master/03-accountabilities/ — кто за что отвечает. Здесь мы собираем из этого работающий ритм.

Зачем событиям быть событиями: эмпиризм как механика

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

События — это моменты, в которые инспекция и адаптация гарантированно случаются. Без них команда либо не инспектирует вообще, либо делает это хаотично: «когда-нибудь обсудим».

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

Две пунктирные ветки — это два способа сломать Scrum, оставив весь календарь на месте. Работа Scrum-мастера в основном сводится к тому, чтобы эти ветки не срабатывали.

Спринт: контейнер, а не отрезок календаря

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

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

Спринт может быть отменён, если цель спринта устарела. Право отмены — только у Product Owner. Это одна из немногих единоличных прерогатив в Scrum, и её любят спрашивать на экзамене.

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

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

Чего делать не стоит:

• Продлевать спринт «на пару дней, чтобы доделать». Это уничтожает ритм и калибровку: команда перестаёт понимать, сколько она реально делает за спринт. Незавершённое возвращается в продуктовый бэклог, и Product Owner решает, что с ним делать.
• Держать «нулевой спринт» для подготовки и «спринт стабилизации» в конце релиза. Первое означает, что вы не умеете начинать с малого, второе — что ваш Definition of Done не про готовность.
• Делать спринты разной длины «по ситуации». Фиксированная длина — это не догма ради догмы: она превращает velocity и любые метрики в сопоставимые числа. Про то, как это связано с измерениями, — https://courses.digitable.life/post/scrum-master/09-empiricism-and-metrics/.

Важная деталь диаграммы: из «Ретроспективы» нет выхода в «конец». Спринты не заканчиваются паузой. Между спринтами нет зазора — это тоже частый вопрос на экзамене.

Планирование спринта: три вопроса, один результат

Что написано в Scrum Guide. Планирование открывает спринт, закладывая работу на него. Таймбокс — максимум 8 часов для месячного спринта, для более коротких обычно короче. Планирование покрывает три темы.

Тема 1: Почему этот спринт ценен? Product Owner предлагает, как продукт может увеличить свою ценность в этом спринте. Вся Scrum-команда совместно формулирует цель спринта — она должна быть готова до конца планирования.

Тема 2: Что можно сделать в этом спринте? Разработчики в обсуждении с Product Owner выбирают элементы продуктового бэклога. Ключевое слово — выбирают разработчики. Product Owner влияет приоритетом и объясняет ценность, но не назначает объём.

Тема 3: Как будет сделана выбранная работа? Разработчики декомпозируют элементы до кусков работы, которые можно завершить (обычно в пределах дня — это рекомендация Guide, не правило). Как именно — целиком решение разработчиков.

Результат всех трёх тем — бэклог спринта: цель спринта (почему) + выбранные элементы (что) + план реализации (как).

Scrum-команда может пригласить других людей для консультации — архитектора, специалиста по безопасности, представителя поддержки.

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

Что делают на практике.

• Цель спринта пишут одним предложением на языке результата, а не списка задач. Плохо: «Сделать задачи PROJ-101, PROJ-104, PROJ-118». Хорошо: «Пользователь может оплатить заказ картой без ухода со страницы корзины».
• Планирование не должно быть первым знакомством с элементами бэклога. Для этого существует непрерывное уточнение бэклога — см. https://courses.digitable.life/post/scrum-master/06-product-backlog/. Если планирование стабильно упирается в потолок таймбокса, проблема почти всегда в неподготовленном бэклоге, а не в самом планировании.
• Ёмкость считают честно: отпуска, дежурства, поддержка, обучение. Команда из шести человек, где двое на дежурстве и один в отпуске, — это не шесть человек.

Чего делать не стоит:

• Начинать планирование с вопроса «сколько story points возьмём?». Это ставит объём выше цели и превращает спринт в мешок задач.
• Позволять менеджеру или Product Owner говорить «возьмите ещё вот это». Продавливание объёма — сигнал, что Scrum-мастеру пора работать с организацией, а не с командой.
• Уходить с планирования без цели спринта. Спринт без цели — это просто две недели работы, и обзор спринта потом не о чем проводить.

Дейли-скрам: 15 минут не про статус

Это событие ломают чаще всего, поэтому разберём его подробнее.

Что написано в Scrum Guide. Цель дейли-скрама — инспектировать прогресс к цели спринта и адаптировать бэклог спринта, корректируя предстоящую запланированную работу. Дейли — 15-минутное событие для разработчиков. Проводится в одно и то же время и в одном и том же месте каждый рабочий день спринта, чтобы снизить сложность.

Если Product Owner или Scrum-мастер активно работают над элементами бэклога спринта, они участвуют как разработчики.

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

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

Что ломается без дейли. Разработчики работают параллельно над одной целью. Каждый день кто-то узнаёт что-то, что меняет план другого: API оказалось не таким, тест нашёл дыру, зависимость подъехала раньше. Без ежедневной синхронизации эти знания расходятся по людям и всплывают на третий день, когда двое уже сделали лишнюю работу. Дейли — это дешёвая ежедневная переприоритизация.

Симптом-тест. Задайте себе вопрос: менялся ли план после дейли хотя бы раз в неделю? Если нет — у вас статус-митинг.

Приём «after-party» (или «шестнадцатая минута») — самое полезное, что Scrum-мастер может внедрить. Как только дискуссия становится технической и касается двух человек из семи, она выносится за таймбокс: «фиксируем, обсудим сразу после, кому надо — останьтесь».

Роль Scrum-мастера. Guide требует, чтобы Scrum-мастер обеспечивал проведение событий и их продуктивность. Но Scrum-мастер не обязан присутствовать на каждом дейли и точно не должен его вести. Зрелая команда проводит дейли сама. Более того: если дейли не может состояться без Scrum-мастера, это диагноз — команда воспринимает событие как отчёт вам.

Чего делать не стоит:

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

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

Обзор спринта: рабочая сессия, а не демо

Что написано в Scrum Guide. Цель обзора — инспектировать результат спринта и определить будущие адаптации. Scrum-команда представляет результаты работы ключевым стейкхолдерам, обсуждается прогресс к цели продукта. Участники совместно решают, что делать дальше. Продуктовый бэклог может быть скорректирован для учёта новых возможностей.

Guide прямо говорит: обзор — это рабочая сессия, и Scrum-команде не следует сводить его к презентации. Таймбокс — максимум 4 часа для месячного спринта.

Обзор — предпоследнее событие спринта. После него идёт ретроспектива.

Что ломается без обзора. Без него команда узнаёт мнение рынка и стейкхолдеров только на релизе. Обзор — это дешёвая проверка гипотезы «мы строим то, что нужно», которая стоит два часа вместо трёх месяцев. Про связь с продуктовыми гипотезами хорошо написано в треке https://courses.digitable.life/post/product-management/00-overview/.

Практические приёмы:

• Показывать инкремент в рабочей среде, а не на слайдах. Ещё лучше — дать стейкхолдерам покликать самим: находится в два раза больше проблем.
• Не приёмка. Если Product Owner впервые видит результат на обзоре, у вас проблема с уточнением и с DoD — Product Owner должен смотреть работу по ходу спринта. Обзор нужен для стейкхолдеров и направления, а не для того, чтобы поставить штамп.
• Незавершённая работа не «показывается наполовину». Она не соответствует Definition of Done, а значит не является инкрементом. Что такое DoD и почему это обязательство, а не чек-лист — https://courses.digitable.life/post/scrum-master/05-artifacts/.
• Обсуждать не только продукт: сроки, бюджет, изменения на рынке — Guide явно упоминает это как часть обзора.

Чего делать не стоит:

• Устраивать театр с репетицией. Час на подготовку слайдов — час, отнятый у продукта.
• Приглашать «всех» и получать сорок человек в зуме, где никто не говорит. Ключевые стейкхолдеры — это те, чьё мнение изменит бэклог.
• Считать обзор моментом, когда PO решает, платить ли команде премию. Об управленческих антипаттернах — https://courses.digitable.life/post/scrum-master/10-antipatterns/.

Ретроспектива: единственное событие про то, КАК вы работаете

Что написано в Scrum Guide. Цель ретроспективы — спланировать способы повышения качества и эффективности. Scrum-команда инспектирует, как прошёл спринт в отношении людей, взаимодействий, процессов, инструментов и своего Definition of Done. Команда обсуждает, что прошло хорошо, какие проблемы встретились и как они были (или не были) решены.

Самые полезные улучшения адресуются как можно скорее; они могут быть даже добавлены в бэклог следующего спринта.

Ретроспектива завершает спринт. Таймбокс — максимум 3 часа для месячного спринта.

Что ломается без ретроспективы. Все остальные события смотрят на продукт. Ретроспектива — единственное, которое смотрит на саму систему работы. Без неё команда может годами повторять одну и ту же ошибку с идеальным velocity. Это разница между «мы быстро едем» и «мы едем туда и умеем ехать быстрее».

Структура, которая работает (классика из книги Derby & Larsen «Agile Retrospectives», pragprog.com):

1. Set the stage — вход, разогрев, напоминание о рамке. 5 минут.
2. Gather data — факты: что произошло. Таймлайн, метрики, эмоции. 15 минут.
3. Generate insights — почему так вышло. Здесь живут «5 почему» и причинно-следственные схемы. 20 минут.
4. Decide what to do — 1–2 конкретных действия с владельцем. 15 минут.
5. Close — как прошла сама ретро. 5 минут.

Шаг 3 пропускают чаще всего: команда прыгает от «было плохо» сразу к «давайте стараться лучше». Именно шаг 3 отличает ретроспективу от жалобной книги.

Правило одного действия. Команда, которая уносит с ретро десять улучшений, не сделает ни одного. Один-два пункта, с именем ответственного и проверкой на следующей ретроспективе. Если улучшение требует реальной работы — оно идёт в бэклог спринта наравне с продуктовой работой, и это прямо разрешено Guide.

Что делают на практике:

• Меняют формат раз в несколько спринтов: «Старт/Стоп/Продолжить», «Парусник», «Таймлайн», «Mad/Sad/Glad». Не ради развлечения, а потому что один формат вытаскивает одни данные и слепнет к другим.
• Периодически проводят ретро по конкретному инциденту — blameless postmortem. Про культуру безвинного разбора — https://courses.digitable.life/post/devops/00-overview/.
• Начинают с «Прайм-директивы» Нормана Керта, когда в команде напряжённо: «независимо от того, что мы обнаружим, мы искренне верим, что каждый делал лучшее, на что был способен в тех обстоятельствах».

Чего делать не стоит:

• Приглашать линейного менеджера, если команда при нём молчит. Психологическая безопасность важнее полноты состава.
• Вести протокол «для отчётности наверх». Ретро мгновенно превращается в дипломатию.
• Отменять ретро «в этот раз ничего не случилось». Именно в спокойные спринты и находятся системные улучшения.
• Проводить ретро до обзора спринта. Порядок в Guide фиксирован: обзор, затем ретроспектива — иначе вы обсуждаете спринт без данных обратной связи от стейкхолдеров.

Уточнение бэклога — не событие

Product Backlog refinement в Scrum Guide 2020 описан как непрерывная деятельность, а не событие. У него нет таймбокса, нет обязательного участника, нет фиксированного места в спринте.

На практике команды выделяют под это регулярный слот (например, час в середине спринта) — и это нормально. Ошибка — называть его «шестым событием Scrum» и требовать на экзамене. События Scrum ровно пять: спринт, планирование спринта, дейли-скрам, обзор спринта, ретроспектива спринта. Спринт при этом — контейнер для остальных четырёх.

Подробно про технику уточнения — https://courses.digitable.life/post/scrum-master/06-product-backlog/.

Таймбоксы: сводная таблица и логика за ними

Три вещи, которые нужно понять про эту таблицу:

1. Числа для месячного спринта — из Scrum Guide. Остальные колонки — практика. Guide говорит только: «для более коротких спринтов событие обычно короче». Пропорции — это здравый смысл, не правило.
2. Дейли всегда 15 минут независимо от длины спринта. Это единственный фиксированный таймбокс.
3. Таймбокс — максимум, а не бюджет. Цель события достигнута за 20 минут — расходимся. Заполнять таймбокс до конца — та же трата, что и его превышение.

Суммарно события съедают около 5–8% времени спринта. Когда кто-то говорит «Scrum — это сплошные встречи», посчитайте: два часа планирования, 2.5 часа дейли, два часа обзора, полтора часа ретро — примерно 8 часов из 80 рабочих часов двухнедельного спринта на человека. Проблема почти всегда не в событиях Scrum, а в наслоившихся сверху статусах, синках и «созвонах по проекту».

Разбор реальных ситуаций

Ситуация 1: «Мы не успеваем, давайте продлим спринт на три дня»

Середина последнего дня, две трети работы готовы, Product Owner предлагает подвинуть обзор.

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

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

Ситуация 2: Дейли превратилось в отчёт тимлиду

Все говорят, глядя на тимлида, длится 30 минут, тимлид раздаёт задачи.

Что делает Scrum-мастер. Не начинает с обвинений. Сначала — данные: «за последние 5 дейли план менялся ноль раз, среднее время 28 минут». Затем эксперимент на два спринта: цель спринта висит на видном месте, обсуждение идёт по элементам работы, а не по людям, разработчики сами ведут событие, Scrum-мастер молчит, всё техническое уходит в after-party. Отдельно — разговор с тимлидом один на один о том, где его экспертиза нужнее. Про работу с такими ролями — https://courses.digitable.life/post/scrum-master/08-coaching-and-conflicts/.

Ситуация 3: Стейкхолдеры не ходят на обзор

Приглашения рассылаются, приходит один аналитик.

Что делает Scrum-мастер. Это симптом, а не проблема расписания. Обычно причина одна из трёх: (а) на обзоре нечего смотреть — показывают слайды или «технические задачи»; (б) стейкхолдеры знают, что их мнение ничего не изменит; (в) обзор поставлен на пятницу в 18:00. Лечение: показать что-то работающее и явно применить обратную связь так, чтобы это было видно в бэклоге на следующем планировании. Люди ходят туда, где на них влияют.

Ситуация 4: Цель спринта разлетелась в первый же день

На дейли выясняется, что внешний сервис, от которого зависела вся цель, недоступен ещё две недели.

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

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

Формат экзамена: 80 вопросов, 60 минут, проходной балл 85%. Подробнее — https://courses.digitable.life/post/scrum-master/12-psm-exam/.

Вопрос 1. Каков таймбокс дейли-скрама для спринта длиной в одну неделю?

• A. 15 минут
• B. 5 минут
• C. Пропорционально длине спринта
• D. Столько, сколько нужно разработчикам

Ответ: A. Дейли-скрам — 15 минут независимо от длины спринта. Это единственное событие с фиксированным таймбоксом. Вариант C — ловушка для тех, кто механически запомнил правило «короче спринт — короче событие»: оно относится к планированию, обзору и ретроспективе, но не к дейли.

Вопрос 2. Кто должен присутствовать на дейли-скраме?

• A. Вся Scrum-команда
• B. Разработчики
• C. Разработчики и Scrum-мастер
• D. Разработчики, Scrum-мастер и Product Owner

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

Вопрос 3. Что происходит с элементами бэклога спринта, не завершёнными к концу спринта?

• A. Спринт продлевается до их завершения
• B. Они автоматически переносятся в следующий спринт
• C. Они возвращаются в продуктовый бэклог, приоритет пересматривает Product Owner
• D. Они засчитываются частично при подсчёте velocity

Ответ: C. Спринт не продлевается никогда. «Автоматически переносятся» — самый популярный неверный ответ: это привычная практика многих команд, но она отнимает у Product Owner решение о приоритете. За спринт мир мог измениться, и незавершённая работа могла потерять смысл. Частичный зачёт (D) противоречит бинарности Definition of Done.

Вопрос 4. Кто отвечает за формулировку цели спринта?

• A. Product Owner
• B. Scrum-мастер
• C. Разработчики
• D. Вся Scrum-команда совместно

Ответ: D. В редакции 2020 цель спринта создаётся всей Scrum-командой на планировании. Product Owner предлагает, как продукт может увеличить ценность, но цель — совместный результат. Вариант A выглядит правдоподобно и был бы ближе к истине в старых трактовках; это типичная проверка на знание актуальной редакции.

Вопрос 5. Спринт-обзор длится дольше запланированного, потому что стейкхолдеры активно спорят о приоритетах следующего квартала. Что должен сделать Scrum-мастер?

• A. Немедленно прервать обсуждение — таймбокс важнее
• B. Продлить обзор: важное обсуждение
• C. Следить за таймбоксом и помочь довести обсуждение до решения об адаптации бэклога, вынеся остальное в отдельную сессию
• D. Ничего: обзор ведёт Product Owner

Ответ: C. Таймбокс — максимум, его нельзя превышать (B неверно), но механическое обрывание ценной дискуссии (A) убивает саму цель обзора. Работа Scrum-мастера — фасилитация: довести до решения то, что относится к обзору, и вынести остальное. Про технику — https://courses.digitable.life/post/scrum-master/07-facilitation/.

Вопрос 6. Кто может отменить спринт?

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

Ответ: B. Единственная единоличная прерогатива такого рода в Scrum. Причина отмены — устаревшая цель спринта. Разработчики и стейкхолдеры могут инициировать разговор, но решение принимает Product Owner.

Вопрос 7. На ретроспективе команда решила, что нужна автоматизация деплоя — это займёт несколько дней работы. Что с этим делать?

• A. Записать в отдельный «технический бэклог» и делать в свободное время
• B. Добавить в бэклог следующего спринта
• C. Запросить у менеджмента отдельный проект
• D. Улучшения процессов не могут занимать время спринта

Ответ: B. Guide прямо говорит: наиболее влиятельные улучшения могут быть добавлены в бэклог спринта следующего спринта. Вариант A — рецепт того, чтобы улучшение не сделали никогда: «свободного времени» не бывает. Вариант D просто неверен.

Как отличить живое событие от мёртвого: чек-лист Scrum-мастера

Правая колонка — это не «плохие люди», а нормальное состояние системы под давлением. Событие деградирует само по себе, если его не поддерживать. Возвращать его в живое состояние — прямая работа Scrum-мастера, и делается это не напоминаниями о правилах, а показом данных и небольшими экспериментами на 1–2 спринта.

Мини-итог

• События Scrum — точки гарантированной инспекции и адаптации, а не встречи в календаре. Критерий состоятельности: что изменилось после события.
• Событий ровно пять. Спринт — контейнер для остальных четырёх. Уточнение бэклога событием не является.
• Таймбоксы: планирование ≤ 8 ч, обзор ≤ 4 ч, ретроспектива ≤ 3 ч для месячного спринта; дейли — всегда 15 минут. Таймбокс — максимум, не план.
• Планирование отвечает на «почему / что / как» и производит бэклог спринта, включающий цель спринта.
• Дейли принадлежит разработчикам и производит план на день, а не отчёт.
• Обзор — рабочая сессия со стейкхолдерами, её результат — изменившийся продуктовый бэклог.
• Ретроспектива — единственное событие про способ работы; она завершает спринт, и улучшения из неё могут попадать прямо в бэклог следующего спринта.
• Спринт нельзя продлить; отменить его может только Product Owner; новый спринт начинается сразу после предыдущего.

Источники

• Scrum Guide 2020 — первоисточник, раздел «Scrum Events». Читать в оригинале обязательно: экзамен проверяет формулировки Guide, а не пересказы.
• Scrum Guide 2020 Revision Highlights — что изменилось в 2020-м, в том числе удаление трёх вопросов из дейли-скрама.
• Esther Derby, Diana Larsen. Agile Retrospectives: Making Good Teams Great — канонические пять фаз ретроспективы.
• Retromat — открытая библиотека форматов ретроспектив, разложенная по фазам.
• Scrum.org: Sprint Goal — практический разбор формулировок целей спринта.
• Kenneth Rubin. Essential Scrum — подробные главы по каждому событию с примерами из практики.
• Трек портала https://courses.digitable.life/post/project-management/01-agile-and-scrum/ — Scrum глазами менеджера проекта, без экзаменационного акцента.

Что дальше

События производят и инспектируют артефакты: цель спринта рождается на планировании, инкремент проверяется на обзоре, Definition of Done обсуждается на ретроспективе. Без понимания артефактов события остаются пустыми ритуалами — поэтому дальше разбираем именно их.

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