Обычно команда формирует список задач, выбирает часть работы на спринт и в конце показывает результат. Product Owner отвечает за приоритеты продукта и ценность задач, Scrum Master помогает команде соблюдать рабочий процесс и устранять препятствия, а участники команды выполняют работу и отвечают за ее результат.

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

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

Андрей Волков советует оценивать Scrum через управленческий эффект. Если собственник не видит, какие решения приняты, что блокирует работу и какой результат получает бизнес, одних ролей и церемоний недостаточно.

Команда запускает новый цифровой сервис и планирует работу спринтами. Product Owner каждую неделю меняет приоритеты, Scrum Master проводит встречи, а разработчики регулярно отчитываются о занятости. При этом критерии готового результата не определены, поэтому задачи формально закрываются, но пользоваться новой функцией клиенты еще не могут. Проблема здесь не в названии метода, а в отсутствии общего понимания результата.