В основном короткие спринты больше нравятся product owner'y, а длинные — разработчикам. Поэтому длина спринта — это всегда компромисс. Мы долго экспериментировали и выбрали нашу любимую длину: 3 недели. Большинство наших команд (но не все) используют трёхнедельный спринт. Достаточно короткий, чтобы предоставить адекватную корпоративную «гибкость», но в тоже время достаточно длинный, для того чтобы команда смогла достигнуть максимальной производительности и успеть решить все вопросы, которые возникнут по ходу спринта.
Мы пришли к важному выводу: экспериментировать с длиной спринта нужно на начальном этапе. Не тратьте слишком много времени на анализ, просто выберите подходящую длину и используйте её на протяжении одного или двух спринтов, после чего можете выбрать новую.
Однако, как только вы найдёте подходящею длину, надолго зафиксируйте её. После нескольких месяцев экспериментов нам подошла длина в 3 недели, поэтому теперь мы следуем этому правилу и используем трёхнедельные спринты. Иногда спринт будет казаться слишком длинным, иногда — слишком коротким. Но сохранение фиксированной длины спринта позволяет выработать корпоративный ритм, в котором все чувствуют себя достаточно комфортно. К тому же исчезнут споры, насчёт даты релиза, так как все знают, что как ни крути, а выпуск новой версии продукта каждые 3 недели.
Это случается практически всегда, когда в ходе нашего планирования я задаю вопрос: «Итак, какова же цель спринта?». Все начинают смотреть на меня удивлёнными глазами, а product owner — морщить лоб, почёсывая свой подбородок.
Почему-то сформулировать цель спринта бывает довольно непросто. Но я до сих пор убеждён, что усилия, потраченные на попытки сформулировать цель, оправдывают себя. Лучше паршивая цель, чем её отсутствие. Например, цели могут быть следующие: «заработать больше денег», «завершить три истории с наивысшими приоритетами», «удивить исполнительного директора», «подготовить систему к бета-тестированию», «добавить возможность администрирования» или что-нибудь в этом духе. Самое главное, чтобы цель была обозначена в терминах бизнеса, а не в технических терминах. То есть языком, понятным даже людям вне команды.
Цель спринта должна отвечать на главный вопрос «Зачем мы работаем над этим спринтом? Почему мы все просто не уйдём в отпуск?». На самом деле, самый простой способ вытянуть цель спринта из product owner'a — напрямую задать ему этот вопрос.
Целью должно быть что-то, что не было ещё достигнуто. «Удивить исполнительного директора» может быть неплохой целью. Но только не в том случае, когда он и так в восторге от текущего состояния системы. В этом случае, все могут просто собраться и пойти домой, а цель спринта всё равно будет достигнута.