Scrum Guide построчно: что там написано на самом деле

Есть один документ, который решает почти все споры о Scrum. Он занимает 13 страниц, читается за сорок минут и бесплатно лежит на scrumguides.org. И при этом подавляющее большинство людей, которые ежедневно «работают по скраму», его никогда целиком не читали. Они знают Scrum по пересказам: по тренингу трёхлетней давности, по настройкам Jira, по тому, как делал предыдущий тимлид.

Отсюда берутся все споры вида «а по скраму так нельзя». Обычно оказывается, что «по скраму» — можно, а нельзя по внутренней традиции конкретной компании.

Эта статья — не пересказ Guide, а инструкция по его чтению. Мы разберём: как устроен документ, какие слова в нём выбраны намеренно, где проходит граница между «написано в Guide», «принято на практике» и «противоречит Guide», и почему на экзамене PSM I половина неправильных ответов выглядит абсолютно разумно.

Если вы ещё не читали Guide целиком — сделайте это прямо сейчас, до продолжения. Русская версия: Scrum Guide на русском (PDF). Дальше будет намного полезнее.

Что это вообще за документ

Первое, что стоит понять: Scrum Guide — не учебник и не методичка. Это определение. Авторы — Ken Schwaber и Jeff Sutherland — фиксируют минимальный набор правил, и всё, что можно было выкинуть, они выкинули.

Историческая динамика показательна: версия 2011 года — 17 страниц, 2017 — 19, а 2020 — 13. Документ не растёт, он усыхает. Из него убирают всё, что можно счесть практикой, а не каркасом.

Полный список изменений с диффами — на scrumguides.org/revisions.html. Для PSM I актуальна только версия 2020, и все вопросы формулируются по ней.

Ещё один нюанс, который часто упускают: Guide опубликован под лицензией Creative Commons Attribution-ShareAlike. То есть его можно свободно копировать, переводить и цитировать — что и делают все тренеры мира.

Карта документа

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

Определение: разбор первых абзацев

«Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.»

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

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

Framework, не methodology. Методология говорит, что делать. Каркас говорит, где границы, а что внутри — ваше дело. Отсюда следует важная вещь: вопрос «а как правильно по скраму декомпозировать задачи?» некорректен. Guide на него не отвечает и не собирается.

Complex problems. Scrum спроектирован для задач, где решение неизвестно заранее. Если вы точно знаете, что и как делать, Scrum не нужен — он будет чистыми накладными расходами. Это прямо связано с моделью Cynefin: сложный (complex) домен требует эмпирики, простой (clear) — обычной инструкции. Про выбор процесса под задачу подробнее в Agile и Scrum и Kanban и поток.

Дальше идёт самая цитируемая фраза Guide:

«Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete… the result is not Scrum.»

Полная формулировка про неизменяемость такая: каркас, как он изложен в Guide, immutable — неизменяемый. Реализовать только часть Scrum возможно, но результат не будет Scrum. И тут же — объяснение, почему это не догматизм:

«Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum…»

Ключевое — «covers up problems», скрывает проблемы. Логика Guide не «делайте как сказано, потому что мы так сказали», а «каждый элемент здесь — детектор проблемы, выкинете его — потеряете сигнал». Это главный ход всего курса: любой элемент Scrum надо уметь объяснить через вопрос «что сломается без него?»

Теория: эмпиризм и бережливое мышление

«Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.»

Эмпиризм — это про то, что план — гипотеза, а не обязательство. Мы не можем предсказать, поэтому строим цикл: сделали кусок → посмотрели на результат → скорректировали. Lean — про то, что всё, что не даёт ценности, надо убрать: лишние документы, лишние согласования, лишние встречи.

Дальше — три столпа. Их порядок тоже важен, потому что это зависимость, а не список:

Guide формулирует это жёстко: «Inspection without transparency is misleading and wasteful». Практический вывод для Scrum-мастера: прежде чем чинить встречи, чините прозрачность. Если доска не отражает реальность, а «Done» означает «я закоммитил, но не тестировал», то никакая идеальная фасилитация дейли не поможет — вы будете инспектировать вымысел.

Четыре пункта, ради которых Scrum-мастер создаёт среду (это дословный список из раздела теории — его любят на экзамене):

1. Product Owner упорядочивает работу над сложной проблемой в Product Backlog.
2. Scrum Team превращает выбранную часть работы в Increment ценности за спринт.
3. Scrum Team и стейкхолдеры инспектируют результаты и корректируются к следующему спринту.
4. Повторить.

Ценности: раздел, который все пролистывают

Пять ценностей: Commitment, Focus, Openness, Respect, Courage (приверженность, фокус, открытость, уважение, смелость). Их добавили в 2016 году, и они выглядят как корпоративный плакат — поэтому их пролистывают. Зря: именно они превращают механику в работающий процесс.

Смотрите, как каждая ценность подпирает конкретный механизм:

Guide прямо связывает ценности со столпами: «Successful use of Scrum depends on people becoming more proficient in living these five values… The Scrum pillars come to life when these values are embodied». Это ответ на классический экзаменационный вопрос «команда механически проводит все события, но результата нет — в чём дело?»

Люди: три ответственности, а не три роли

В 2020 году слово role заменили на accountability — ответственность. Разница не косметическая: роль — это должность, ответственность — это то, за что человек отвечает головой. Один человек может нести несколько ответственностей, и Scrum-мастер может быть Developer’ом в той же команде.

Что важно из формулировок:

• Scrum Team — обычно 10 человек или меньше («typically 10 or fewer people»). Не «7±2», это формулировка из старых версий. И это typically, не must.
• Внутри Scrum Team нет подкоманд и иерархий («no sub-teams or hierarchies»). В 2020 убрали разделение на «Development Team внутри Scrum Team» — теперь это одна команда.
• Product Owner — один человек, а не комитет («one person, not a committee»).
• Scrum Master «accountable for establishing Scrum» и «accountable for the Scrum Team’s effectiveness» — за результативность команды, не за её загрузку.
• Термин «servant-leader» из 2017 заменён на «true leader who serves» — акцент сместился с «слуги» на «лидера».

Детальный разбор — в следующей статье трека «Три ответственности». Здесь важно другое: Guide не описывает, как эти люди работают между собой в деталях. Он задаёт границы ответственности — остальное вы выстраиваете сами.

События: точные формулировки и точные таймбоксы

Guide называет пять событий, но структура у них не плоская: Sprint — это контейнер, внутри которого происходят остальные четыре.

Что тут стоит запомнить дословно:

• Sprint — «fixed length events of one month or less». Не «две недели». Не «от одной до четырёх». Верхняя граница есть, нижней нет.
• Новый спринт начинается сразу после завершения предыдущего. Никаких пауз, никаких «недель между спринтами».
• Sprint Planning — до 8 часов для месячного спринта, три темы: Why (Sprint Goal), What (что берём), How (как сделаем).
• Daily Scrum — 15 минут, независимо от длины спринта. Для Developers. Guide 2020 убрал три вопроса («что сделал / что сделаю / что мешает») — их больше нет в документе, структуру Developers выбирают сами.
• Sprint Review — до 4 часов. Ключевая фраза: «It is a working session and the Scrum Team should avoid limiting it to a presentation». То есть демо — не то же самое, что Review.
• Sprint Retrospective — до 3 часов, завершает спринт («concludes the Sprint»).

Обратите внимание, что для спринтов короче месяца Guide говорит только «events are usually shorter» — никакой формулы там нет. Пропорция «неделя → четверть от месячных таймбоксов» — это разумная практика, а не правило.

Ещё несколько формулировок, которые почти дословно всплывают в вопросах PSM I:

«Only the Product Owner has the authority to cancel the Sprint.»

«A Sprint could be cancelled if the Sprint Goal becomes obsolete.»

«No changes are made that would endanger the Sprint Goal… Scope may be clarified and renegotiated with the Product Owner as more is learned.»

Последняя пара — источник вечной путаницы. Цель спринта неприкосновенна, объём — обсуждаем. Это принципиально разные вещи, и на экзамене их постоянно подменяют. Подробный разбор событий — в статье 04.

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

Каждому артефакту в 2020 году приписали commitment — обязательство, которое делает артефакт прозрачным и даёт критерий проверки прогресса.

Точные формулировки, которые важны:

• Product Goal — «the long-term objective for the Scrum Team». Он живёт в Product Backlog. Цель одна за раз: «A Scrum Team must have one objective (Product Goal) to work toward at a time.»
• Sprint Goal — «the single objective for the Sprint». Единственная. Создаётся во время Sprint Planning и добавляется в Sprint Backlog.
• Sprint Backlog принадлежит Developers: «It is a plan by and for the Developers». Не PO и не Scrum-мастер решают, что туда попадёт технически.
• Increment — «work cannot be considered part of an Increment unless it meets the Definition of Done». Полуготовое в инкремент не входит вообще.
• Множественные инкременты: «Multiple Increments may be created within a Sprint». И — «The Sprint Review should never be considered a gate to releasing value». Релизить можно в любой момент спринта.
• Если у организации есть общий Definition of Done, все команды обязаны следовать ему как минимуму; команда может его ужесточить, но не ослабить.

Разбор артефактов вглубь — в статье 05.

Чего в Scrum Guide нет

Вот тут начинается самое ценное для практики и для экзамена. Огромный пласт того, что люди считают «правилами скрама», в документе просто отсутствует.

Слой 2 — популярные практики, которых нет в Guide (и это не значит, что они плохие):

• Story points, velocity, burndown-диаграммы. Ни одного из этих слов в Guide нет. Есть только «size» и указание, что размер определяют те, кто будет делать работу. Про то, как ими злоупотребляют, — статья 09.
• Пользовательские истории и формат «Как <роль>, я хочу…». Guide говорит только «Product Backlog item» — это может быть что угодно.
• Planning Poker, T-shirt sizing, идеальные дни. Ни один способ оценки не предписан. Про них — в оценке и планировании.
• Доска задач, колонки To Do / In Progress / Done, Jira. Guide не требует ни доски, ни инструмента.
• Definition of Ready. Этого термина в Guide нет вообще. В 2017 была фраза про элементы, «deemed Ready», в 2020 её убрали. DoR — практика, часто вырождающаяся в мини-водопад: «мы не возьмём задачу, пока аналитик не напишет ТЗ».
• Backlog Refinement как событие. Уточнение бэклога в Guide есть, но это «ongoing activity» — постоянная деятельность, не событие и без таймбокса. Формулировка «на рефайнмент отводится до 10% времени команды» — из версии 2011 года, её давно убрали.
• Оценка в часах, capacity planning, роль тимлида, техдолг — всего этого в тексте нет.

Слой 3 — то, что противоречит Guide:

• «Спринт 0» для подготовки и «спринт стабилизации» перед релизом — в спринте всегда создаётся потенциально пригодный инкремент, иначе спринт не выполняет свою функцию.
• Scrum-мастер или PO раздаёт задачи разработчикам — Sprint Backlog принадлежит Developers.
• Спринт длиннее месяца или переменной длины.
• Перенос «почти готового» в инкремент.
• Отмена ретроспективы «потому что горим».
• Изменение Sprint Goal в середине спринта (менять объём — можно, цель — нет).

Как этим пользоваться на работе. Когда команда спорит «а по скраму так можно?», у Scrum-мастера три варианта ответа, и надо различать их вслух: (1) «Guide это прямо предписывает», (2) «Guide об этом молчит — решаем сами, вот трейд-оффы», (3) «Это противоречит Guide, и вот какой сигнал мы потеряем». Смешивать эти три регистра — самый быстрый способ превратиться в «полицейского процесса», которого никто не слушает.

Как читать формулировки: must, should, may

Guide написан аккуратно, и модальные глаголы там не случайны. На экзамене это решает исход вопроса.

Практическое следствие: если в вопросе экзамена вариант ответа звучит как абсолют («всегда», «никогда», «обязательно должен»), а Guide в этом месте говорит typically — вариант почти наверняка неверный. И наоборот: если Guide говорит «is», а вариант предлагает «может быть по-разному» — тоже мимо.

Сценарии: Guide против реальности

Сценарий 1. «У нас двухнедельные спринты, но релиз раз в квартал». Что говорит Guide: инкремент должен быть usable — пригодным к использованию — к концу спринта. Он не требует релизить каждый спринт. Решение о выпуске принимает Product Owner. Что делать Scrum-мастеру: не бороться с квартальным релизом напрямую. Сделать прозрачным вопрос «сколько стоит нам то, что готовое лежит три месяца», и подсветить время цикла. Тема живёт на границе со статьёй про DORA-метрики.

Сценарий 2. «Менеджер требует, чтобы дейли был для отчёта ему». Что говорит Guide: Daily Scrum — событие для Developers, чтобы инспектировать прогресс к Sprint Goal и адаптировать план. Guide не запрещает наблюдателей, но встреча не для них. Что делать: не выгонять менеджера силой. Дать ему то, что он хочет (прозрачность), другим каналом — доступ к доске, короткая сводка, приглашение на Sprint Review. Дейли остаётся встречей планирования, а не статуса.

Сценарий 3. «PO в середине спринта приносит срочную задачу». Что говорит Guide: объём можно уточнять и перепроговаривать с PO по мере получения новых знаний. Цель спринта менять нельзя. Если цель устарела — PO вправе отменить спринт. Что делать: разложить вопрос на два. Помогает ли новая задача достижению Sprint Goal? Если да — Developers сами решают, что подвинуть. Если нет и она правда критична — значит цель устарела, и это разговор об отмене спринта, а не о тихом впихивании задачи.

Сценарий 4. «Команда 18 человек». Что говорит Guide: обычно 10 или меньше; если команда слишком велика, стоит реорганизоваться в несколько сплочённых Scrum Team с общими Product Goal, Product Backlog и Product Owner. Что делать: это уже разговор про масштабирование — статья 11 и фреймворки масштабирования.

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

Экзамен проверяет знание именно текста Guide, а не «здравого смысла из практики». Потренируемся.

1. Кто определяет размер (size) элементов Product Backlog? a) Product Owner b) Scrum Master на основании исторических данных c) Developers, которые будут делать эту работу d) Вся Scrum Team голосованием

Ответ: c. Guide: «The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.» PO влияет, но не определяет. Вариант (d) звучит «эджайлово» и потому соблазнителен, но Guide отдаёт это Developers.

2. Спринт длится две недели. Сколько длится Daily Scrum? a) 7–8 минут, пропорционально длине спринта b) 15 минут c) Столько, сколько нужно команде d) Не более 30 минут

Ответ: b. Daily Scrum — 15 минут всегда, вне зависимости от длины спринта. Это единственный таймбокс, который не масштабируется. Ловушка (a) эксплуатирует привычку пропорционально уменьшать всё остальное.

3. В середине спринта выясняется, что Sprint Goal недостижим. Что делать? a) Developers продлевают спринт на неделю b) Scrum Master отменяет спринт c) Scrum Team обсуждает это с Product Owner и при необходимости перепроговаривает объём работ d) Спринт продолжается, цель переносится на следующий

Ответ: c. Длина спринта фиксирована — (a) отпадает. Отменить спринт может только PO — (b) отпадает по субъекту. Guide прямо разрешает уточнять и перепроговаривать объём с PO по мере получения новых знаний. Отмена — крайняя мера, когда цель устарела, а не просто «трудна».

4. Что из перечисленного обязательно должно быть готово к концу Sprint Planning? a) Полностью декомпозированный план на весь спринт по часам b) Sprint Goal, выбранные элементы бэклога и план на ближайшие дни работы c) Оценка всех элементов в story points d) Утверждённая дата релиза

Ответ: b. Guide: Developers планируют работу, необходимую для создания инкремента, «for the first days often to a Day or less» — то есть детальный план нужен не на весь спринт. Story points в Guide нет вовсе, (c) отпадает автоматически.

5. Какое утверждение о Sprint Review верно? a) Это демонстрация, на которой Scrum Team показывает результат стейкхолдерам b) Это gate: без одобрения на Review инкремент нельзя выпускать c) Это рабочая сессия, на которой Scrum Team и стейкхолдеры обсуждают, что делать дальше, и Product Backlog может быть скорректирован d) На нём Product Owner принимает или отклоняет работу разработчиков

Ответ: c. Guide прямо предостерегает от сведения Review к презентации и прямо говорит, что Review — не ворота для выпуска ценности. Вариант (d) — распространённое искажение: PO не «принимает работу», критерий готовности — Definition of Done.

6. Сколько Sprint Goal может быть у спринта? a) По одной на каждого разработчика b) Одна c) Столько, сколько элементов взято в спринт d) Guide не регламентирует

Ответ: b. «The Sprint Goal is the single objective for the Sprint.» Это одно из самых буквальных мест в документе — и именно поэтому его любят на экзамене.

Больше разборов и стратегия сдачи — в статье про экзамен.

Типичные ошибки при чтении Guide

• Читать через призму своего проекта. «У нас так нельзя» — это не аргумент против текста, это диагноз организации. Сначала поймите, что написано, потом решайте, что с этим делать.
• Путать отсутствие запрета с предписанием. Guide молчит о Jira — значит, Jira ни обязательна, ни запрещена. Ответ «нельзя, потому что этого нет в Guide» неверен по логике.
• Считать Guide исчерпывающим руководством. Он намеренно неполон. Фасилитация, коучинг, работа с продуктом, инженерные практики — всё за его пределами. Именно поэтому в этом курсе есть фасилитация и коучинг.
• Учить наизусть, не понимая назначения. PSM I проверяет не память, а понимание: большинство вопросов — ситуационные. Зубрёжка ломается на первом же сценарии.
• Читать старую версию. Материалов по 2017 в интернете больше, чем по 2020. Если видите «три вопроса дейли», «Development Team» или «роли» — перед вами устаревший текст.

Мини-итог

• Scrum Guide — определение каркаса, а не методичка. 13 страниц, лицензия CC BY-SA, актуальная версия — ноябрь 2020.
• Структура документа идёт от теории (эмпиризм, бережливое мышление, три столпа) к ценностям и только потом к механике. Читать надо в этом же порядке.
• Каркас неизменяем не из догматизма: каждый элемент — детектор проблемы. Выкидывая элемент, вы выкидываете сигнал.
• Три столпа связаны зависимостью: без прозрачности инспекция вводит в заблуждение, без адаптации инспекция бессмысленна.
• В 2020 роли стали ответственностями, исчез термин Development Team, убраны три вопроса дейли, добавлены обязательства: Product Goal, Sprint Goal, Definition of Done.
• Нет в Guide: story points, velocity, burndown, user stories, Definition of Ready, доски, рефайнмент как события. Всё это — практики, а не правила.
• Различайте три регистра ответа: написано в Guide / не написано, решаем сами / противоречит Guide. Это главный профессиональный навык Scrum-мастера в спорах о процессе.
• На экзамене следите за модальностью: typically и should — не must.

Источники

• The Scrum Guide (scrumguides.org) — первоисточник, версия ноября 2020
• Scrum Guide Revisions — диффы между версиями
• Scrum Glossary (Scrum.org) — термины, которых нет в самом Guide
• Ken Schwaber, Jeff Sutherland. Software in 30 Days — контекст появления Scrum
• Scrum.org: Open Assessments — бесплатные тесты Scrum Open и Product Owner Open
• Cynefin Framework (cognitive-edge.com) — про сложные и простые домены

Что дальше

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

Три ответственности: Product Owner, Scrum Master, Developers