Смысл Sprint в том, чтобы доставить ценность заинтересованным лицам. Однако, простое следование списку Sprint Backlog Item (например, задач), не обязательно приводит к созданию максимально возможной ценности.
Когда команда создает план работ исходя из индивидуальных задач или результатов, легко взять отдельный элемент и работать над ним индивидуально в течение Production Episode. Однако, это снижает возможность инноваций, возникающих в результате коллаборации людей, которые привносят в работу различные точки зрения. Офисные стены могут стать барьерами на пути к непрерывному общению, которое важно для всех разработчиков (участников Development Team) и всей команды в целом. Страдает командная работа.
Команде, возможно, надо частично перепланировать текущий Sprint, чтобы убедиться, что ценность будет создана к концу Sprint.Новая работа может появиться в самый последний момент, и команда должна обновить план. Следование первоначальному плану может привести к тому, что максимально возможная ценность не будет создана. Другое частое явление — в ходе Sprintстановится понятно, что команда не завершит все Элементы Sprint Backlog. Это часто происходит потому, что объем работы, необходимой для завершения Элемента Бэклога Спринта, увеличивается.
Другой сценарий, когда команде для разработки Product Backlog Item (PBI) нужно получить важные технические знания. Разработчикам (или даже Product Owner) может понадобиться технический прототип, чтобы проверить архитектуру или узнать рабочие характеристики технологии. Несмотря на то, что PBI должен идентифицировать такую работу, его неопределенный характер требует, чтобы команда сфокусировалась на получении знаний, а не на завершении всей запланированной работы. Технический прототип становится критическим пунктом для успеха Sprint.
Иногда наибольшая ценность не привязана к конкретному Product Backlog Item. Например, наибольшей ценностью для команды было увеличение дохода за Sprint, и команда посвятила Product Backlog Item этой цели. С другой стороны, иногда большая часть ценности в Sprint связана с одним конкретным PBI.
Следовательно:
Scrum Team привержена достижению короткой формулировки ценности, которую она создает во время Sprint. Она становится фокусом всей работы в течение Sprint.
Sprint Goal должна быть прозрачна для команды; например, помещена на Скрам Доску или использована в другом Information Radiator.
Development Team продолжает держит Sprint Backlog в актуальном состоянии во время Sprint, поддерживая достижение Sprint Goal. Прогресс выполнения Sprint Backlog (как показано на Sprint Burndown Chart) подобен прогрессу на футбольном поле: хотя каждый ярд движения по полю приближает мяч к финалу, ценность приходит только, когда гол забит в ворота. Иногда возможно достичь Sprint Goal, не завершив все SBIs. Это помогает командам справляться с непредвиденными ситуациями и дает Developersгибкость в изменении их рабочего плана каждый день во время Daily Scrum. Например, возникающие препятствия могут поставить под угрозу достижение Development Team всего Sprint Backlog. В этом случае команда автоматически прибегает к Sprint Goal как к «Плану Б», не тратя долгие часы на перепланирование.
Согласно исследованию, проведенному Университетом Карнеги-Меллон, команды, которые заранее готовятся к прерываниям, справляются с ними на 14% лучше. Команды, которые готовятся к прерываниям, завершают задачи, на которые прерываются, на 43% быстрее.
Теоретически возможно постоянное достижение Sprint Goal когда каждый Sprint завершается только часть PBIs. Это должно быть редкостью, потому что Sprint Backlog должен соответствовать Sprint Goal; если этого не происходит, то существует серьезная проблема с Value Stream.
Скорость (см. Notes on Velocity) помогает командам понять, работают ли они все правильно. Sprint Goal помогает командам убедиться в том, что они разрабатывают правильные вещи. Речь идет о понимании того, «почему» команда разрабатывает что-то, для фокуса в случае изменений.
Джефф Сазерленд добавляет, что кроме фокуса Sprint Goalпоощряет Swarming: Можем ли мы стимулировать всех работать над чем-то одним вместе? Он рассказывает:
В Кремниевой Долине в 2007 году компания Palm работала над Web OS, которая впоследствии была приобретена компанией Hewlett-Packard. Каждый Sprint команды хорошо работали, пока через пару Sprints не появилось ощущение, что они уперлись в стену. PBIs не заканчивались. Разработчики были демотивированы и рано уходили домой. Меня пригласили и совместно с Product Owners и Scrum Masters мы провели час, опрашивая членов команды о том, почему они демотивированы. Мы обнаружили, что они не понимают, почему они должны усердно работать над низкоуровневыми PBIs.
Мы провели послеобеденное время, разбирая Product Backlog, показывая четкую связь между историями высокого уровня и иерархией декомпозиции. Как только разработчики поняли, что Sprint Goal было улучшение производительности Web OS на 10%, у них появилась мотивация завершить низкоуровневые истории, и скорость вернулась к норме.
Для разработчиков, и особенно для глубоких экспертов, важно понимать, почему разрабатываются PBI(s).
Sprint Goal обычно имеет отношение к Ценности Продукта. Команда может альтернативно связать Sprint Goal с процессами, например: “выполнять всю работу через парное программирование”, или “появляться вовремя на Daily Scrum каждый день”.