В этой статье мы рассмотрим частый практический вопрос: можно ли изменять бэклог спринта после его запуска и какие проблемы подсвечивает этот вопрос?
Есть распространённое убеждение, что бэклог спринта нельзя изменять, если спринт уже запущен. Почему?
Кто-то считает, что это показывает, что планирование спринта у команды плохого качества. Но тогда строгий запрет на изменение состава спринта только скрывает проблему.
Кто-то говорит, что если команда получает право на изменение состава спринта, она будет планироваться более легкомысленно и в порядке вещей станет раздувать истории/брать неясные истории в спринт до их разъяснения. Если на команду сверху давит менеджмент, который не понимает разницы между прогнозом и точным сроком, то ситуация усугубляется ещё больше.
Кто-то считает, что раз цель спринта не может измениться, то и бэклог спринта тоже не может меняться.
Так должен ли бэклог спринта быть фиксированным или гибким?
Во-первых, на что нужно согласиться, так это то, что мы не можем идеально запланировать сложность. Вокруг появляется много неожиданностей, и команде нужно уметь с этим работать — адаптировать.
Бэклог меняется постоянно, он может делать это ежедневно, учитывая результат Дейли. Вокруг постоянно возникают неясности, которые нельзя предусмотреть: например, баг перерастает в сложную доработку, а доработка вызывает собой регрессивное тестирование вокруг. С опытом эти неясности будут сокращаться, но мы должны оставлять команде право на ошибку в прогнозах. Планировать сложность идеально на старте невозможно: чем больше мы работаем над задачей, тем больше узнаём.
Команда даёт обещание достигнуть цели спринта, а не завершить бэклог спринта. Это достигается через ежедневную адаптацию новых обстоятельств к тому, как достичь цели спринта лучшим образом.
Молодым scrum-мастерам можно посоветовать перестать волноваться о метриках и смотреть на продуктовые цели и бизнес-ценность.
Тем не менее, постоянное изменение скопа спринта может показывать некоторые нездоровые вещи, которые нужно исправлять быстрее, чем вводить правила:
- задачи раздуваются из-за слабой архитектуры системы/легаси и проч. Обсудите с командой то, как вы будете бороться с техническим долгом, и начните это делать.
- скоуп раздувается из-за необходимости регрессии — нет ли пробелов в unit- и автотестировании, которые должны помочь в этом случае?
- неясные требования со стороны бизнеса — коучинг владельца продукта и стейкхолдеров, что является темой отдельной статьи, и по нашему мнению, является самой сложной проблемой из списка.
В общем, не ставьте ограничений и лишних правил, пытайтесь адаптироваться к новым вводным здесь и сейчас, при этом не закрывая глаза на глубинные проблемы, которые точно стоят за этой потребностью.
