Первоначально это зависело от используемого шаблона процесса.В шаблоне Scrum была ошибка, приравниваемая к элементам журнала невыполненных работ по продукту, и это означало, что они были в списке незавершенных работ по продукту и не могли быть задачами в списке незавершенных работ Sprint.В шаблоне Agile все было наоборот, в MSF Agile было обычным сообщать о работе непосредственно над ошибками.
В 2013 году была введена функция, позволяющая настроить ошибку при обнаружении ошибок:
Руководство по этой функции можно найти здесь:
Белый халат схваткиОтвет тренера
Как тренер Scrum.org, у меня также есть более пристрастное мнение по этому поводу.Когда вы работаете над элементом журнала невыполненных работ (или историей пользователя в зависимости от соглашения об именах) и обнаруживаете проблему с ним в спринте, это не ошибка, вы просто нашли задачу, о которой не знаетееще не закончил как команда.Следовательно, ошибки в спринте регистрируются как Задача в исходном элементе журнала невыполненных работ (/ История пользователя).
Если вы обнаружите ошибку во время спринта, которая не связана с текущей работой, вы бы нене сразу поднимите его и исправьте, вместо этого вы поместите его в Журнал ожидания продукта и поработаете с владельцем продукта, чтобы выяснить, когда имеет смысл втянуть его в спринт.Затем вы создадите план для его исправления в рамках планирования Sprint (и добавите задачи в Bug, как если бы это было для любого другого элемента журнала невыполненных работ по продукту).
В этой настройке вы никогда не будете работать напрямую сОшибка, безусловно, не будет вносить изменения в код против ошибки.
Вы, конечно, должны выяснить, что лучше всего подходит для вас и вашей команды, но это своего рода «разбор по книге», способ взглянуть наошибки, относящиеся к журналу невыполненных работ по продукту и спринту.
Источник: https://scrumcrazy.wordpress.com/2018/09/22/one-way-to-handle-production-support-and-bugs-in-scrum-bradley-bug-chart/