✂️ Как разделить User Story, чтобы команды могли их завершить

Если ваши User Story регулярно переходят из спринта в спринт - вы столкнулись с классической проблемой: задачи слишком крупные. Команда занята, иллюзия прогресса есть, но показать нечего.

Главная причина - синдром 90%, когда разработчик искренне верит, что большая задача выполнена на 90%, и так каждую неделю. Решение не в том, чтобы работать быстрее, а в том, чтобы иначе резать работу.

Ключевая ошибка - делить историю по техническим слоям: отдельно бэкенд, отдельно фронтенд, отдельно база данных. Это не помогает создать ценность. Вы получаете кучу зависимостей, ни одну историю нельзя показать заказчику.

Правильный способ - вертикальное разделение: узкий, но законченный сценарий, который проходит через все слои и дает работающую ценность. Даже если это всего два поля поиска вместо двадцати - это работает и тестируется.

Хороший сплит - это всегда ограничение. Начните с одного типа пользователя, одного бизнес-правила, одного рабочего пути. Используйте SPIDR: поищите разные пути, интерфейсы, правила или данные, чтобы отрезать кусок.

Цель - не нарезать задачи на "сделать то-то", а получить маленькую, но завершенную историю с критериями приемки. Если историю нельзя показать на обзоре спринта - вероятно, вы нарезали задачи, а не ценность.

Практический совет: планируйте разбиение примерно за два спринта до старта, не раньше. Разделять должны вместе - владелец продукта отвечает за ценность, разработчики за техническую реализуемость.

Если команда говорит "Эту историю нельзя разделить" - попробуйте три шага: приложите больше усилий и используйте SPIDR, разрешите сделать два спринта на одну историю (как редкое исключение) и пусть команде будет слегка некомфортно от такого решения. Это не даст большим User Story стать нормой.

LinkedIn: Mike Cohn, Scrum Guide Co-author & Owner - Mountain Goat Software

📖 Читать статью (~9 минут)