Scrum - Добавить заполнитель для будущей истории
Практикуя Scrum и Agile, у нашей команды было планирование спринтов, и мы разделили наши функции на истории. Однако наша команда не была уверена в том, что должна делать «третья» история, поэтому Скрам-мастер решил, что мы можем ввести заполнитель для этой истории на нашей доске до тех пор, пока дальнейшая информация не будет передана команде обратно из ЗП. Заполнитель - это общая история, указывающая на то, что подлежит уточнению. Соответствует ли использование заполнителя для истории процессу Agile и Scrum?
Ответы
Ваш владелец продукта должен быть доступен во время планирования, чтобы ответить на любые возникающие вопросы, касающиеся историй. Если вопрос не может быть решен, потому что владелец продукта не присутствовал или не мог в достаточной степени ответить на вопрос, тогда история не готова и не должна быть в спринте.
Заполнитель - не лучшая идея. Планирование спринта составляет план на следующие две недели. Если вы не знаете деталей, вы не сможете составить план. Вы не можете планировать с пустой картой.
Самая большая проблема здесь - это то, что «ретранслируется обратно в команду из ЗП». Заказчик на поставку является частью команды и частью планирования . У PO нет доверенного лица, через которое передается информация, это единственное доступное лицо, с которым вы можете напрямую поговорить и обсудить свои вопросы . Если это не так, что-то не так в вашей реализации Scrum.
nvoigt очень хорошо сформулировал проблему. Я бы просто добавил, что каждый спринт должен работать над элементами с наивысшим приоритетом в бэклоге в то время, поэтому тот факт, что одна из этих вещей в некоторой степени неизвестна, говорит о том, что не было достаточного внимания к тому, что является наиболее важным.
Многие команды Scrum часто «дорабатывают» бэклог, добавляя новые истории, детали и оценки, чтобы убедиться, что приоритетные истории готовы к работе к тому времени, когда они войдут в планирование спринта. Эта деятельность по уточнению бэклога является обязанностью всей команды, включая PO. Руководство по Scrum предполагает, что команды должны тратить до 10% времени в каждом спринте на уточнение бэклога.
ИМХО, короткий ответ на это: да, нет ничего плохого в том, чтобы иметь заполнители для будущих историй (и это хороший инструмент, чтобы не забывать о работах в будущих спринтах)
Более длинный ответ, заполнители должны быть уточнены перед планированием спринта, как упомянул Nvogel. Если это не так, & PO отсутствует или не может ответить немедленно на совещании по планированию (которое я видел несколько раз), команда разработчиков может решить, могут ли они зафиксировать элемент в спринте или нет. Фактор неопределенности может быть рассчитан для увеличения размера объекта (который впоследствии занимает больше места для других объектов).