JIRA/Agile: неправильное название Sprint? Или неправильная методология? Или ..?

Question

Я как-то через проект, на третьем спринте, который посвящен обработке на заднем плане. Пусть, скажем, имя спринта «3. Слияние данных и формирование формы». У меня есть 4 или 5 функций в этом спринте, которые относятся непосредственно к этой задаче, и я на полпути, хотя некоторые из них завершены, а некоторые нет.

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

Похоже, что в это время было бы уместно отказаться от моей текущей работы на заднем плане и обратиться к обратной связи. Причина в том, что, обратившись к проблемам пользовательского интерфейса, это прекратит распространение «неправильности» для остальной части приложения (Lotus Domino: вот как это работает).

У JIRA нет средств для удержания Sprints и запуска нового. Вам нужно закрыть спринт.

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

Это было похоже на квадратное круглое отверстие, и я не уверен, как это «должно быть» с Agile или JIRA.

Так что мой вопрос: Являются ли проблема, что ..

1. Нейминга спринтов не должен включать в себя слишком много обязательств по своей природе, поэтому в том числе задачи пользовательского интерфейса с спринтом, предназначенным для серверной обработки не будет расстраивать вещи.
2. Если спринт «прерван» таким образом, мое представление о его удержании и отвлечении внимания на другой спринт - это не то, как работает Agile (следовательно, JIRA не позволит вам). Что-то еще должно произойти (если да, что?)
3. JIRA менее гибкая, чем требования Agile (кажется, очень маловероятно!)
4. Некоторые другие вещи, о которых я не думал.

Answer 1

Типичный подход к области изменения среднего Спринт выглядит следующим образом:

Если изменение является относительно незначительным и как команда и владелец продукта согласен, то вы идете вперед это сделать. Обычно команда будет компенсировать любые изменения, например, когда они приносят новую историю, они также выведут такую ​​же историю, чтобы чистый эффект на спринт был близок к нулю.

Если изменения значительны the Product Owner may terminate the sprint. Команда немедленно начинает планировать новый спринт таким же образом, как обычно.

Не все так часто называют спринт с подробностями о спринте. Просто используя простое числовое имя спринта (например, sprint 1, sprint 2), вы можете помочь понять, что команда Scrum открыта для изменения.

В JIRA, если спринт был разорван раньше, я бы обозначил его как полностью, а затем создал новый спринт. Это может немного испортиться с вычислением скорости, но должно быть достаточно легко компенсировать.