Что такое Scrum простыми словами: спринты, артефакты и роли

Вячеслав Степанов — проджект-менеджер, ментор · 16 сентября 2026

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

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Что такое Scrum

Scrum — это способ работать над продуктом маленькими повторяющимися циклами, которые называются спринтами (обычно 1–4 недели, чаще всего — две). Каждый спринт команда берёт небольшую порцию работы, доводит её до готового результата и показывает. Потом — следующий спринт. И так раз за разом.

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

При чём тут Agile

Scrum часто путают с Agile, но это разные вещи. Agile — это не методология, а набор принципов из манифеста 2001 года:

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

А Scrum — конкретный фреймворк, построенный под эти принципы: со спринтами, ролями и правилами. Второй по популярности agile-фреймворк — Kanban, и большинство современных команд на деле работают по их гибриду. Об этом ниже.

Три артефакта — три вопроса

Весь Scrum держится на трёх источниках информации. Проще всего запомнить их через вопросы, на которые каждый отвечает:

• Product Backlog — «Что нам нужно сделать?» Общий список всего, что может понадобиться продукту: фичи, улучшения, фиксы. Сверху — важное и проработанное, снизу — сырые идеи на будущее. Список живой и постоянно меняется, отвечает за него один человек — Product Owner. Думай об этом как о большом списке желаний, отсортированном по важности.
• Sprint Backlog — «Что мы делаем прямо сейчас?» В начале каждого спринта команда берёт верхнюю, самую важную часть Product Backlog — ровно столько, сколько реально успеет. Этот список принадлежит команде: в течение спринта она фокусируется именно на нём, не отвлекаясь на остальное.
• Increment — «Что мы уже сделали?» Реальный, работающий результат спринта. Не «почти готово», а законченный кусок продукта, которым можно пользоваться.

Роли: кто за что отвечает

• Product Owner — решает, что делаем: отвечает за Product Backlog и приоритеты.
• Scrum Master — помогает команде следовать процессу: следит, чтобы ритуалы работали, а помехи убирались.
• Команда разработки — делает Increment: разработчики, тестировщики, дизайнер.

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

Как выглядит спринт живой команды

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

• Планирование спринта — понедельник 1-й недели, полтора часа: команда собирает Sprint Backlog;
• Дейлик — каждый рабочий день, 15 минут: синхронизация и блокеры;
• Груминг бэклога — среда 1-й недели, час: разбор и оценка будущих задач;
• Демо — четверг 2-й недели, полчаса: показываем инкремент;
• Ретроспектива — пятница 2-й недели, час: обсуждаем, как улучшить процесс.

Честная цифра, которую стоит знать заранее: на все эти встречи уходит порядка 15–20% рабочего времени команды. Это цена предсказуемости — и главный аргумент критиков Скрама.

Когда Scrum подходит, а когда нет

Scrum выбирают, когда есть продуктовая разработка с неопределённостью, команда из 5–9 человек и нужна предсказуемая ритмика: веб-сервисы, мобильные приложения, продукты, которые активно меняются.

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

И главная правда, которую редко пишут в учебниках: жёсткие правила Скрама применяют редко — почти все команды адаптируют фреймворк под себя. Большинство современных продуктовых команд работает по скрамбану — гибриду: ритмика и ритуалы от Scrum плюс доска и поток задач от Kanban. Задачи при этом живут на доске в Jira — как это устроено, я подробно разбирал в статье про Jira и Confluence.

Частые вопросы