Изменения в пользовательской истории после спринта запустились [закрытый]

Какие типы изменений / дополнений / дополнительных уточнений, по вашему мнению, можно внести в пользовательскую историю (после начала спринта)?

Любые, о которых просит Владелец продукта и для команды Scrum все еще комфортно поддерживать свои обязательства по завершению всех пользовательских историй, выполненных в спринте.

какие изменения / дополнения / дополнительные пояснения, по вашему мнению, не могут произойти с пользовательской историей (после начала спринта)?

Любые, о которых спрашивает владелец продукта for и делают команду Scrum неудобной для выполнения своих обязательств по завершению всех пользовательских историй, выполненных в спринте.

Вы можете отменить спринт. Или, возможно, перенести проблемные элементы в новый спринт? Тем самым сокращая продолжительность текущего спринта. Но, по сути, я говорю, что все, что сильно влияет на продолжительность или результат спринта, будет нашей точкой принятия решения. Только ты можешь реально оценить то, что я бы сказал.

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

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

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

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

Разъяснения всегда должны приветствоваться как часть разговора. Изменения, не влияющие на общую историю, должны быть разрешены, если команда считает, что у нее есть время завершить запрошенные изменения в текущем спринте. И дополнениями, как правило, должны быть новые истории, если только команда не считает, что у них есть время, и им будет легче сделать это во время текущего спринта.

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

Я думаю, все зависит от команды, ведущей переговоры с владельцем продукта. В некотором смысле, ЛЮБЫЕ изменения в пользовательской истории, которые влияют на реализацию истории, недопустимы.

Команда взяла на себя обязательство создать пользовательскую историю, как это было указано при планировании спринта. Любые изменения, внесенные позже, не были частью обязательства, поэтому владелец продукта (при условии, что именно здесь происходят изменения) должен знать, что любые изменения требований должны быть подписаны командой.

Опять же, это очень ограничительный способ решения этой проблемы.

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

1. Оставить другую пользовательскую историю или уменьшить объем другой пользовательской истории.
2. Постарайтесь уместить все, но имейте список дополнительных задач, которые вы можете пропустить, если время истечет.
3. Добавьте ресурсы в команду. Пусть спринт продлится еще на несколько дней.
4. Напишите новую пользовательскую историю для изменений и расставьте приоритеты, чтобы она попала в следующий спринт.
5. Отбросьте измененную пользовательскую историю для этого спринта, перепишите пользовательскую историю и сделайте это в следующем спринте.

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