Создатели Scrum Guide обращают внимание, что отмена спринта — это действие, которое может «травмировать» команду, оно должно применяться в крайних случаях. Тем не менее, есть ситуации, когда приходится завершать спринт раньше срока. Что делать в этом случае? Куда уходят недоделанные карточки и сожжённые SP? В этой статье мы разберёмся в практической части вопроса.
Отмена спринта — это решение на основе стоимости и ценности. Обычно оно принимается владельцем продукта, когда цель устаревает. Это может быть вызвано внезапными ситуациями, к которым нужно быстро адаптироваться.
В каком-то смысле, возможность отменить спринт повышает гибкость, хотя и является нежелательным развитием событий. Это позволяет начать делать что-то более ценное и срочное, но требует сильной, приверженной команды.
Спринт не отменяется, если команда не справляется с работой.
Если в течение спринта добавляются новые (срочные) пользовательские истории, это тоже не отменяет спринт.
Если команда не может закончить работу вовремя и понимает это заранее, это тоже не отменяет спринт. Она делает работу до логической точки и продолжает ее в следующем спринте.
Спринт не отменяется и тогда, когда работа завершена раньше срока. Тогда добавляются новые истории.
Когда поводы отменить спринт появляются часто, это показывает несколько вещей:
- команде не хватает сосредоточенности,
- спринт слишком длинный, а рынок требует быстрой адаптации,
- не достаточно чёткое видение продукта даже на ближайшую перспективу,
- приоритеты владельца продукта не соблюдаются вышестоящим руководством или заказчиком.
Вредно отменять спринт ещё по тому, что в этом случае нарушается ритм работы: метрики командной работы поедут, а команду может заштормить.
Когда лучше отменить спринт?
Иногда бывают ситуации, когда лучше не затягивать. Иногда неудачные проекты тянут слишком долго, тогда как от них можно просто отказаться и сэкономить ресурсы.
Общая причина отмены спринта — изменившаяся цель, которая перечеркивает всю предыдущую работу и не может быть добавлена несколькими новыми карточками.
Несколько стандартных ситуаций:
- спрос на продукт или услугу, которые поставляет команда, прекратился. Тогда задачи, включённые в спринт, теряют приоритет. В этом случае команда должна перепланироваться и сменить направление.
- команда попадает под сокращение бюджета, что может вести к изменению штата, доступных ресурсов.
Если ситуации не такие глобальные, то спринт нужно сохранять. Когда прошла 1 неделя из 4-ёх недельного спринта, ещё есть время перепланировать работу и достичь новой цели. С другой стороны, если команда прошла более 2/3 спринта, будет слишком поздно для того, чтобы добиться значимого результата.
Если спринт длится одну-две недели, то отмена спринта может обойтись дороже и редко имеет смысл. Именно поэтому Scrum использует короткие итерации.
В случае отмены команда собирается вместе, чтобы адаптировать это изменение. Незавершенная работа из бэклога спринта переоценивается и возвращается в бэклог продукта. Если она полезна и когда-либо будет завершена, она остаётся в бэклоге. Если это трата времени, незавершённые PBI выкидываются.
Если до отмены спринта появилась выполненная работа, то владелец продукта одобряет её и обычно выпускает инкремент. Определение того, что сделано, а что нет, может быть сложным: часто у тасков есть зависимости от отменённой работы. Это ещё одна причина, почему отмена спринта — травматичное событие.
Делать ли для части готовой работы ревью и ретроспективу по отменённому спринту, нужно решать в конкретной ситуации, в которой находится команда. Как нам кажется, ретроспективу проводить нужно, если не сразу после отмены, то хотя бы после следующего полного спринта.
А вы сталкивались с отменой спринта или с желанием команды прекратить спринт раньше? Что делали в этом случае?