Нужны ли вам спринты фиксированной длины?

Если кратко, то:

1. Да, спринты фиксированной длины очень сильно помогают, когда команда только начинает, она еще не сработана, и вы не знаете реальной velovcity этой команды на этом проекте. Эта задает ритмичность и столь необходимые искусственные ограничения.

2. Спринты дают комфортное чувство дедлайна 😉 - можно сосредоточиться на понятном скоупе работ, и выбросить на две недели из головы часть мыслей о приоритезации и следующих задачах. “Комфортное” - потому что дедлайн для решений не каждый день, а раз в спринт.

3. Обратная сторона: это ведет к неизбежным подтасовкам: мы либо берем слишком маленькую цель (ведь задача спринта - сделать явный инкремент в продукте), либо придумываем цель под те таски, которые поместились в спринт после оценки команды.

4. Последний вариант, к сожалению, самый частый. У этого много причин:
* РО не успевает или не может придумать явную цель с понятным инкрементом
* продукт имеет большое количество пользователей (особенно это касается В2В энтерпрайз) и есть много мест, которые нужно пофиксить “на вчера”
* спринты сложены из багов или техдолга, а не исходят из цели.

5. Основная проблема со спринтами: мы опасаемся брать большие значимые цели, которые сделают многих счастливыми, потому что они ТОЧНО не помещаются в спринт. Что делать в таком случае:
* Для этого существуют эпики. Эпик может длиться более одного спринта (в отличие от истории).
* Эпики все равно нужно бить на части, и эти части должны быть более-менее независимыми друг от друга в части функционала (это сложная тема, которую в комментарии не раскрыть, но это возможно).
* Попробовать (это челлендж лично для меня, с учетом энтерпайз продукта, в который коммитят 20+ скрам-команд) добиться выпуска shippable инкремента КАЖДЫЙ СПРИНТ. Покрытого юнит и интеграционными тестами, с зелеными тест-планами, сданного по Definition of Done, принятых в вашей компании. По этому пункту я планирую написать больше в ближайшее время.

Красивый пост с картинками, который меня вдохновил (очень рекомендую): https://hackernoon.com/fixed-length-iterations-vs-continuous-flow-afd0d32ab50

P.S. Идея отказаться от спринтов ради более гармоничной работы вокруг целей разного объема (не подпиливать их под 14 дней) мне пока кажется нецелесообразным. Пока более разумной выглядит мысль брать задачи объемом меньше спринта, которые могут быть явно отданы в релиз, а оставшееся время просто начинать делать следующие задачи из топа бэклога. При этом успешность спринта оценивать только по основной цели, а не дополнительным задачам.