Бэклог спринта — это список задач, которые команда взяла на следующий спринт. Каждый разработчик дал обязательство выполнить все элементы бэклога до конца спринта. Считается, что никакие изменения во время спринта не допускаются: новую работу нельзя добавить или убрать старую. Это обстоятельство даёт команде фокус на определённых задачах.
Но так ли это на самом деле? Что говорит Scrum Guide, что получается на практике и в каких случаях допускаются изменения?
В бэклог спринта попадают итемы из бэклога продукта, которые соответствуют единой цели спринта. Цель ставится во время планирования, то есть до начала фактической работы. Мы уже касались разновидностей целей на спринт, и если вкратце, то это может быть «проверка предположения» или «состояние инкремента», которого собирается достичь команда.
В ScrumGuide делается больший акцент именно на цели спринта, а не на точном объёме работ. Команда решает, сколько элементов бэклога отобрать и как их выполнять, но всё это подчиняется цели.
При этом нигде не сказано, что бэклог спринта будет неизменен в течение двух-четырёх недель. Это противоречит философии гибкой разработки о том, что мы не можем создавать подробные планы наперёд.
Команды сталкиваются с тем, что по ходу разработки открываются новые задачи. Их включение в текущий спринт может быть оправдано, и это не противоречит ScrumGuide:
Как должна поступать scrum-команда?
Что-то может пойти не так в процессе разработки, и изменения в бэклоге будут оправданы, так как без них нельзя достигнуть цели спринта.
Необходимость изменений может обнаружиться на ежедневном стендапе. На нём происходит проверка прогресса и адаптация. В этом случае команда должна пересмотреть бэклог спринта вместе с владельцем продукта. Раньше в ScrumGuide было написано, что на планировании команда берёт обязательства выполнить отобранные задачи. На практике часто случалось иначе, и чтобы написанное не противоречило с реальным применением фреймворка, «обязательство» заменили на «прогноз». Когда команда прогнозирует работу на следующий спринт, она в праве отредактировать его уже в ходе итерации.
Главное, изменения не должны мешать цели спринта, помогать в её достижении, инициироваться или одобряться самой командой. Бэклог спринта является таким же гибким, как и всё в Scrum.
Зачем нужен этот миф?
Иногда миф о том, что бэклог спринта нельзя менять, может оказаться полезным.
Во-первых, в отношениях команды разработки и других отделов. Часто происходит так, что на scrum-команду «навешивают» всё новые задачи, которые отвлекают её от достижения цели спринта. Легче сказать окружающим это категоричное правило, чем доказывать, что случайная задача отвлекает от цели. Это временная мера, и сильные организации стремятся познакомить с гибкой разработкой всю компанию, но мы же понимаем, что эта проблема не решается парой семинаров.
Во-вторых, это может помочь команде на первых порах, когда представление о целях слишком размыты. Команда может втискивать в рамки спринта как можно больше задач, а это повлияет на качество реализации. Решение об изменении спринта должно быть взвешенным.
В заключение
Спринт в гибкой разработке имеет свойство меняться. Если команда анализирует свою работу, поощряйте это. Улучшение бэклога спринта —это не только добавление новых задач (что точно порадует менеджера), но и удаление неактуальных, мешающих. Любые изменения должны работать на цель спринта и гарантировать полезный инкремент продукта.