Введение в SCRUM: краткое руководство

Что такое Scrum и зачем он нужен

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

В чем ценность Scrum, становится понятно при сравнении с водопадным/классическим подходом (Waterfall), который предполагает, что требования зафиксированы в начале и не изменятся, однако на практике так почти не бывает. Фреймворк Scrum строится на обратной посылке: требования будут меняться, и работать нужно короткими циклами с постоянной проверкой результата.

Устройство помогает запомнить правило 3:5:3 — три роли, пять событий, три артефакта. Масштаб подтверждают цифры State of Agile Report 2024 (Digital.ai): Agile применяет 71% компаний, а самый популярный фреймворк — Scrum, его используют 87% Agile-команд.

Краткая история: от регби до Кремниевой долины

Термин пришел из регби: scrum — схватка, в которой команда движется к цели как единое целое. В деловой оборот его ввели Хиротака Такэути и Икудзиро Нонака в статье «The New New Product Development Game» (Harvard Business Review, 1986), описав команды, работающие «как в регби».

Формализовали фреймворк Кен Швабер и Джефф Сазерленд на конференции OOPSLA 1995 года в Остине, синтезировав существующие идеи в минимальную обучаемую систему. Институциональными опорами стали Scrum Alliance (2001) и scrum.org (2009). С 2010 года авторы публикуют Scrum Guide — официальное описание фреймворка; актуальная версия вышла в 2020 году.

Scrum vs Agile: в чем разница

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

Четыре ценности Agile-манифеста:

• люди и взаимодействие важнее процессов и инструментов;

• работающий продукт важнее исчерпывающей документации;

• сотрудничество с заказчиком важнее согласования контракта;

• готовность к изменениям важнее следования плану.

Ценности Agile реализуют также другие фреймворки: Kanban, XP (Extreme Programming) и SAFe. Отсюда ключевой тезис: команда может быть Agile без Scrum, но не может по-настоящему применять Scrum, не будучи Agile.

Три столпа и пять ценностей Scrum

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

Подход Scrum держится на трех столпах.

• Прозрачность (Transparency): работа видима всем — Sprint Backlog открыт команде, Product Backlog доступен стейкхолдерам.

• Инспекция (Inspection): прогресс и артефакты регулярно проверяются — для этого встроены события.

• Адаптация (Adaptation): по итогам инспекции курс корректируется — Sprint Retrospective существует ради этого.

Пять ценностей задают характер команды:

• Преданность (Commitment) — команда берет реалистичные обязательства и выполняет их;

• Сфокусированность (Focus) — работа спринта важнее посторонних задач;

• Открытость (Openness) — проблемы и прогресс обсуждаются честно;

• Уважение (Respect) — участники считают друг друга компетентными;

• Смелость (Courage) — команда поднимает трудные вопросы и берется за сложное.

Четыре принципа работы Scrum (4C)

Дополнительная линза — фреймворк 4C.

• Communication: нет скрытых блокеров, проблемы озвучиваются на Daily Scrum.

• Collaboration: PO и разработчики не сидят в «силосах», Sprint Planning выполняется совместно.

• Commitment: цели спринта реалистичны, взятое доводится до конца.

• Continuous Improvement: ретроспективы дают реальные изменения, а не протоколы.

Разграничение простое: ценности определяют характер команды, 4C — ежедневные поведенческие ожидания.

Роли в Scrum-команде

Ролей ровно три, и это намеренно: минимальный набор, закрывающий ценность, процесс и создание продукта. Разделение ответственности удобно запомнить по короткой формуле: Product Owner отвечает за то, чтобы делать правильные вещи, разработчики — чтобы делать вещи правильно, Scrum Master — чтобы делать их быстро. Команда небольшая, кросс-функциональная и самоуправляемая; оптимум — до 10 человек: 3–9 разработчиков плюс PO и SM. Это не иерархия: ни одна роль не «главнее», у каждой своя зона подотчетности.

Product Owner (PO) — голос бизнеса и приоритетов

Product Owner отвечает за максимизацию ценности продукта. Инструмент — Product Backlog: PO владеет им, упорядочивает и обеспечивает прозрачность. Обязанности: сформулировать Product Goal (долгосрочную цель), приоритизировать бэклог, прояснять требования на Sprint Planning, принимать или отклонять результаты на Sprint Review.

PO представляет интересы стейкхолдеров, но это один человек, а не комитет: конфликтующие директивы убивают скорость. Требования часто оформляют как User Story: «Как [роль], я хочу [функция], чтобы [ценность]». Критическое разграничение: PO определяет, ЧТО строить, — но не КАК: способ выбирают разработчики.

Scrum Master (SM) — слуга-лидер, а не менеджер проекта

Scrum Master — слуга-лидер (servant leader), отвечающий за понимание и соблюдение фреймворка. Служит трем субъектам: команде — фасилитирует события и коучит самоуправление; PO — помогает с бэклогом и Product Goal; организации — устраняет системные препятствия.

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

Команда разработчиков — кросс-функциональное и самоуправляемое ядро

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

Оптимум — 3–9 человек, и это арифметика: меньше — не хватает кросс-функциональности, больше — координация съедает продуктивность. Разработчикам принадлежит и Sprint Backlog: план составляют те, кто будет его исполнять.

Артефакты Scrum: что создаем и отслеживаем

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

Нововведение Scrum Guide 2020 — обязательства (commitments): Product Backlog — Product Goal, Sprint Backlog — Sprint Goal, Increment — Definition of Done. Обязательства придают артефактам направленность: понятно не только «что есть», но и «зачем».

Бэклог продукта (Product Backlog): живой список приоритетов

Product Backlog (бэклог продукта) — упорядоченный список всего необходимого для улучшения продукта и единственный источник работы команды. За содержание и порядок отвечает PO. Принципиальное свойство: бэклог никогда не «завершен» — он меняется вместе с продуктом и рынком.

Элементы часто описываются как User Story — формат не предписан Scrum Guide, но принят за понятность. Поддерживает бэклог Backlog Refinement (уточнение, или «груминг») — непрерывная активность по детализации и оценке. Это не отдельное событие: команда выделяет на нее до 10% времени спринта.

Бэклог спринта и цель спринта (Sprint Goal)

Sprint Backlog (бэклог спринта) — план на спринт из трех частей: Sprint Goal (почему спринт ценен), выбранные элементы Product Backlog (что будет сделано) и план поставки (как). Владеют артефактом разработчики — не PO и не SM.

Цель спринта (Sprint Goal) — один четкий тезис, а не список задач: он дает связность и оставляет гибкость в выборе способов. Для прогнозирования емкости служит Velocity (скорость) — среднее число story points (условных единиц сложности) за 3–5 спринтов; это инструмент планирования, а не оценка производительности. Оценивают задачи через Planning Poker: числа Фибоначчи (1, 2, 3, 5, 8, 13, 21) принуждают к независимому мышлению, а «рваная» шкала честно отражает неточность больших оценок.

Definition of Ready (DoR): когда задача готова к спринту

«Sprint Planning»: (критерии готовности) — чеклист, которому элемент должен соответствовать до включения в спринт. Контраст: DoR — входные ворота, DoD — выходные.

Типовой чеклист: элемент описан как User Story; определены Acceptance Criteria (критерии приемки); команда дала оценку; зависимости идентифицированы; объем укладывается в спринт. Не прошедшие элементы возвращаются в бэклог.

Оговорка: DoR не входит в Scrum Guide 2020 — в отличие от DoD. Это практический паттерн сообщества, защищающий спринт от сырых задач.

Инкремент и Definition of Done: когда работа считается завершенной

Инкремент (Increment) — сумма элементов бэклога, завершенных за спринт и соответствующих Definition of Done. Ключевое требование: он пригоден к использованию (useable), даже если релиз не планируется. Выпускать или нет, решает PO; готовность обеспечивает команда.

Критерии завершенности (Definition of Done) — формальное определение качества, единое для команды, зафиксированное письменно. Правило жесткое: не соответствует DoD — не часть инкремента, возвращается в Product Backlog. Расплывчатый DoD порождает болезнь «99% готово»: работа копится месяцами и никогда не поставляется.

Диаграмма сгорания (Burndown Chart): визуальный «пульс» спринта

Диаграмма сгорания (Burndown Chart) показывает оставшуюся работу относительно времени — мгновенный индикатор здоровья спринта. Ось X — дни спринта, ось Y — оставшийся объем в условных баллах сложности задач (story points). Идеал — прямая диагональ из левого верхнего угла в правый нижний; фактическая линия идет ступеньками, и ее отклонение сигнализирует о рисках раньше слов.

Обновляется диаграмма ежедневно, удобнее сразу после Ежедневного ритуала «Обзор работы» (Daily Scrum).

Scrum-доска: прозрачность работы в реальном времени

Скрам-доска (Scrum Board) — инструмент визуального управления с тремя колонками: To Do (не начато), In Progress (в работе), Done (соответствует DoD). Одного взгляда достаточно, чтобы увидеть состояние спринта, — доска напрямую реализует столп Прозрачности.

Физическая доска со стикерами подходит офисным командам, цифровые (Jira, Kaiten, Trello) — распределенным. Формат вторичен, первично ежедневное обновление, так как считается, что устаревшая доска хуже отсутствующей: она создает ложную картину.

События Scrum: пять церемоний фреймворка

Пять событий — сам Спринт (Sprint), Планирование спринта (Sprint Planning), Дэйлики (Daily Scrum), Обзор спринта (Sprint Review), Ретроспектива спринта (Sprint Retrospective). Каждое событие — это контрольная точка инспекции и адаптации; пропуск любого разрывает цикл обратной связи и извлечения нового опыта, на котором держится эмпирический подход Agile.

Дисциплину обеспечивает тайм-бокс (timebox) — жесткий максимум продолжительности; минимума нет. Это механизм принудительной эффективности: ограниченное время заставляет говорить о главном.

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

Спринт — сердцебиение фреймворка: период 1–4 недели, внутри которого происходят остальные события и создается инкремент. Большинство выбирает две недели: короче спринт — быстрее обратная связь, но выше накладные расходы; длиннее — наоборот.

Два правила защищают спринт.

• Правило 1. Изменения, угрожающие цели спринта (Sprint Goal), недопустимы — это охраняет концентрацию.
• Правило 2. Отменить спринт может только PO и только с пересмотром цели спринта. Важно и постоянство длительности спринта: одинаковые спринты создают ритм и делают прогнозируемой производительность команды для будущих спринтов.

Sprint Planning: с чего начинается каждый спринт

Sprint Planning (планирование спринта) открывает спринт: команда отвечает на три вопроса.

• Почему спринт ценен? — ответ становится целью спринта (Sprint Goal).

• Что может быть сделано? — из бэклога продукта (Product Backlog) выбираются элементы.

• Как будет выполнена работа? — разработчики составляют план.

Для планирования спринта проводится отдельная встреча, длительностью до 8 часов для месячного спринта; для двухнедельного — около 2 часов. Оценка сложности каждой работы в бэклоге спринта проводится с помощью специального подхода «Покер планирования» (Planning Poker), суть которого — услышать общее мнение команды, и уж точно не использовать «нормативы». Задачи, не прошедшие проверку на определение критериев их готовности (Definition of Ready (DoR)), возвращаются в бэклог продукта, так как планировать «сырое» запрещено.

Daily Scrum: 15 минут, которые синхронизируют команду

Дэйлики (Daily Scrum) — 15-минутное ежедневное событие разработчиков: инспекция прогресса разработки и адаптация Sprint Backlog на день. Принципиально: это не отчет менеджменту, событие принадлежит разработчикам; Scrum Master обеспечивает проведение, но не ведет его.

Три классических вопроса, на которые отвечает каждый участник команды:

• что сделано вчера;

• что будет сделано сегодня;

• какие есть препятствия.

Sprint Review: показываем инкремент, собираем обратную связь

Sprint Review (обзор спринта) — совместная инспекция выполненной работы командой и стейкхолдерами, длительность (тайм-бокс) — до 4 часов для месячного спринта.

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

Полезно разграничение:

• Sprint Review инспектирует продукт;

• Sprint Retrospective — процесс создания этого продукта.

Sprint Retrospective: двигатель непрерывного совершенствования

Sprint Retrospective (ретроспектива) — событие, которое закрывает спринт: команда «инспектирует себя», проектные процессы, применяемые инструменты разработки решений, а также планирует улучшения. Тайм-бокс — до 3 часов для месячного спринта.

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

Роль Scrum Master — обеспечивать безопасный разговор, в котором команда честно называет реальные проблемы.

Как выглядит Scrum на практике: пошаговый запуск первого спринта

От теории — к практике. Проверенная последовательность запуска:

1. Сформировать команду: 3–9 разработчиков, владелец продукта (PO), скрам-мастер (SM).

2. Провести обучение — ввести участников команды в роли, познакомить с предстоящими событиями (планирование спринта, дэйлики и т. д.).

3. Проверить описание работ на соответствие критериям готовности (Definition of ready) к тому, чтобы задача была взята в работу.

4. Создать начальный бэклог продукта (Product Backlog) с понятной всем целью спринта (Sprint Goal). Осторожно: без цели бэклог — свалка пожеланий.

5. Провести первый Sprint Planning: длина спринта (в начале можно идти короткими спринтами — до двух недель). Осторожно: главная ошибка новичков — набрать больше задач, чем реально сделать.

6. Запустить спринт с ежедневными дэйликами (Daily Scrum). Осторожно: «пятнадцатиминутки» норовят растянуться на час, удерживайте жесткий тайм-бокс.

7. Провести Обзор спринта (Sprint Review) со стейкхолдерами. Осторожно: слайды вместо работающего инкремента — тревожный симптом отсутствия понятного, готового к демонстрации результата с минимальной функциональностью.

8. Закрыть спринт ретроспективой как первой точкой честного разговора о процессе и эффективности работы команды. Осторожно: без зафиксированного улучшения встреча-ретроспектива считается пройденной впустую.

Первый спринт будет несовершенным — это нормально: Agile рассчитан на обучение с каждым циклом.

Инструменты для Scrum: трекеры задач и цифровые дашборды

Три категории инструментов.

• Agile-трекеры: Kaiten — российская альтернатива при импортозамещении.

• Визуальная коллаборация, например, Holst — доски для проведения ретроспективы распределенных команд.

• Легкие решения для отслеживания ежедневного прогресса: Trello и Notion для малых команд.

Оценка успеха в Scrum: метрики и показатели эффективности

Как понять, что фреймворк работает? Ключевые метрики «здоровья» проекта:

• Скорость команды (Velocity) — средний объем (в story points) выполненных задач за спринт. Сравнивать команды по Velocity бессмысленно: у каждой своя шкала.

• Диаграмма сгорания (Burndown Chart) — ежедневное состояние спринта; ранний детектор отставания.

• Время нахождения задачи в бэклоге (Lead Time) — от попадания задачи в бэклог до поставки результата.

• Время цикла (Cycle Time) — от начала работы до завершения; эффективность самого процесса.

• Удовлетворенность заказчика — собирается на Sprint Review; проверка, что скорость не подменила ценность.

Типичные ошибки при внедрении Scrum

«Это скрам, но…» (ScrumBut) — использование отдельных частей фреймворка при уверенности, что внедрен он весь.

Распространенные ошибки скрама и в чем опасность каждой:

• «Daily Scrum проводим нерегулярно» — рвется ежедневный цикл инспекции, проблемы копятся неделями.

• «Спринты длиннее месяца» — теряется итеративность, получается классический подход управления проектами (waterfall) с новым названием.

• «Ретроспективы пропускаем» — команда лишается механизма совершенствования и повторяет ошибки.

• «Критерии завершенности (DoD) отсутствуют или размыты» — инкремент теряет пригодность, задачи копятся как «почти готовые», но не принятые заказчиками.

• «Бэклогом управляют все понемногу» — приоритеты размываются, команда работает над случайными задачами.

• «Скрам-мастер как менеджер проекта» — самоуправление умирает, остается переименованная иерархия.

Решение распространенных проблем при внедрении Scrum

• Проблема «Сопротивление изменениям». Решение: начинать с малого — одна команда, один продукт; фиксировать метрики «до» и «после», чтобы говорить языком результатов.

• Проблема «Нечеткие роли». Решение: воркшоп на реальных кейсах — абстрактные описания из книг не приживаются.

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

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

Scrum и Kanban: когда что выбрать

Оба фреймворка принадлежат Agile, но решают разные задачи; выбор — вопрос характера работы, а не моды.

Масштабирование Scrum: когда одной командой не обойтись

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

Четыре подхода дают разный баланс простоты и формальности.

1. Scrum of Scrums (SoS) — простейший механизм: каждая команда делегирует представителя на межкомандный стендап — что сделала, что сделает, какие блокеры между командами.

2. LeSS (Large-Scale Scrum) — 2–8 команд с одним PO, одним Product Backlog и общими Review и ретроспективами; высокие требования к владельцу продукта.

3. SAFe (Scaled Agile Framework) — самый «enterprise-дружелюбный» и самый сложный, сообщество относится к нему неоднозначно.

4. Nexus — фреймворк Кена Швабера для 3–9 команд: добавляется лишь Nexus Integration Team.

Рекомендация практиков: масштабирование — вопрос не первого года. Сначала одна зрелая команда, потом тиражирование.

Заключение

Scrum обманчиво прост: все правила умещаются на 13 страницах Scrum Guide, а мастерство требует многолетней практики. Фреймворк легко описать — и трудно исполнять честно, без «но».

Часто задаваемые вопросы

Нужна ли сертификация по Scrum, чтобы внедрить его в команде?

Нет, для внедрения сертификация не обязательна: официальный Scrum Guide бесплатен и содержит все правила фреймворка. Обучение по программе ценно другим — систематизацией знаний, разбором сложных практических случаев и формальным подтверждением компетентности, которое востребовано работодателями при найме и продвижении.

Можно ли применять Scrum не в IT-проектах?

Да. Scrum эффективен везде, где есть сложность и неопределенность требований: маркетинговые кампании, дизайн, образовательные продукты, производственные и исследовательские проекты. Роли, события и артефакты переносятся без изменений — меняется лишь содержание инкремента: вместо программного кода это может быть кампания, курс или прототип.

Чем Scrum Master отличается от менеджера проекта?

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

Какую длину спринта выбрать для начала?

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

Сколько человек должно быть в Scrum-команде?

По Scrum Guide — до 10 человек: 3–9 разработчиков плюс Product Owner и Scrum Master. Меньше трех разработчиков — не хватает кросс-функциональности для создания инкремента; больше девяти — координация становится узким местом, и команду имеет смысл разделить, перейдя к масштабированию.

Глоссарий терминов Scrum

Бэклог продукта — Product Backlog — Упорядоченный перечень всего необходимого для улучшения продукта. Это постоянно обновляемый перечень приоритетов, единственный источник работы для команды. За содержание и порядок отвечает владелец продукта.

Бэклог спринта — Sprint Backlog — План работы на спринт, состоящий из цели спринта, отобранных задач из бэклога продукта и плана их выполнения. Принадлежит разработчикам.

Владелец продукта — Product Owner (PO) — Отвечает за получение наибольшей ценности от продукта. Управляет бэклогом продукта, устанавливает долгосрочную цель, расставляет приоритеты и разъясняет требования. Определяет, ЧТО создавать, но не КАК.

Водопадная (каскадная) модель — Waterfall — Классический подход, в котором все требования фиксируются в самом начале и считаются неизменными.

Время нахождения в бэклоге — Lead Time — Показатель эффективности: время от появления задачи в бэклоге до ее поставки заказчику.

Время цикла — Cycle Time — Показатель эффективности процесса: время от начала работы над задачей до ее завершения.

Гибкая методология (разработки) — Agile — Совокупность ценностей и принципов, описанных в Манифесте 2001 года. Это философская основа, а не конкретный набор правил.

Диаграмма сгорания — Burndown Chart — Наглядный график, показывающий объем оставшейся работы в спринте по дням. Обновляется ежедневно и помогает вовремя заметить отставание.

Ежедневное событие (Дэйли) — Daily Scrum (Daily) — Ежедневная пятнадцатиминутная встреча разработчиков для проверки хода работы и корректировки плана на день. Это не отчет перед руководством.

Инкремент — Increment — Сумма всех завершенных за спринт задач, которые отвечают критериям завершенности. Главное требование — результат готов к использованию, даже если выпуск пока не планируется.

История пользователя — User Story — Способ описания требований через фразу: «Как [роль], я хочу [действие], чтобы [польза]». Удобен для понимания, но не является обязательным по руководству.

Команда разработчиков — Developers — Все специалисты, создающие результат: программисты, дизайнеры, испытатели, аналитики. Это самоуправляемое и разностороннее ядро команды. Оптимальная численность — от 3 до 9 человек.

Критерии готовности— Definition of Ready (DoR) — Перечень условий, которым должно соответствовать описание задачи, чтобы ее можно было включить в спринт. Это «входной фильтр». Практическое дополнение, которого нет в официальном руководстве 2020 года.

Критерии завершенности — Definition of Done (DoD) — Четкое, письменно зафиксированное определение качества, общее для всей команды. Если работа не соответствует этим критериям, она не входит в инкремент и возвращается в бэклог продукта.

Критерии приемки — Acceptance Criteria — Условия, которым должна отвечать история пользователя, чтобы считаться принятой. Входят в типовой перечень критериев готовности.

Обзор спринта — Sprint Review — Совместная встреча команды и заинтересованных лиц для проверки выполненной работы. На ней смотрят на сам продукт, а не на процесс. Это рабочее обсуждение, а не торжественная сдача результатов.

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

Покер планирования — Planning Poker — Способ оценки сложности задач, при котором каждый высказывает свое мнение (используются числа Фибоначчи), чтобы прийти к общему решению, а не к усредненному нормативу.

Ретроспектива спринта — Sprint Retrospective — Встреча, завершающая спринт: команда рассматривает свою работу, процессы и инструменты, чтобы найти способы улучшений. Если улучшение не запланировано, встреча считается проведенной зря.

Скрам-доска — Scrum Board — Наглядный инструмент с тремя разделами: «Предстоит», «В работе» и «Сделано». Помогает видеть состояние дел и обеспечивает прозрачность.

Скрам-мастер — Scrum Master (SM) — Руководитель-слуга, который следит за пониманием и соблюдением правил фреймворка. Помогает команде, владельцу продукта и всей организации. Не раздает задания и не контролирует их выполнение.

Скорость команды — Velocity — Средний объем выполненной работы за спринт (в условных единицах сложности). Используется для планирования, а не для оценки эффективности. Сравнивать разные команды по этому показателю бессмысленно.

Спринт — Sprint — Основа всего процесса: отрезок времени от 1 до 4 недель, внутри которого проходят все остальные события и создается готовый результат. Две недели — лучший выбор для начала в большинстве команд.

Тайм-бокс — Timebox — Строгое ограничение по времени для каждого события. Помогает сосредоточиться на главном и не тратить время впустую.

Условные единицы сложности — Story Points — Относительные баллы для оценки трудоемкости задач, на основе которых рассчитывается скорость команды. Шкала Фибоначчи (1, 2, 3, 5, 8, 13, 21) честно показывает, что крупные задачи оценивать точнее нельзя.

Уточнение бэклога — Backlog Refinement — Постоянная работа по уточнению и оценке задач в бэклоге продукта. Это не отдельная встреча; команда тратит на это до 10% времени спринта.

Цель продукта — Product Goal — Долгосрочный ориентир, который задает владелец продукта. Это обязательство, придающее смысл бэклогу продукта.

Цель спринта — Sprint Goal — Единая четкая формулировка, объясняющая, зачем нужен этот спринт. Она объединяет задачи и дает свободу в выборе способов их решения. Это обязательство для бэклога спринта.

«Это скрам, но…» — ScrumBut — Ситуация, когда применяются лишь отдельные части фреймворка, но команда считает, что использует его целиком. Формальная обертка без содержания, возникающая при непонимании основ.

Эмпирический подход — Empirical approach — Подход, при котором знания добываются через опыт, а решения принимаются на основе наблюдаемых фактов, а не заранее составленных планов. Строится на трех столпах: прозрачность, проверка и приспособление.