Я являюсь частью команды разработчиков, которая относительно новичок Scrum, предположим, что в конце спринта несколько больших историй были in progressили не были acceptedв ПО.
Во-первых, что происходит с этими пользовательскими историями? Вы просто переносите их в следующий спринт?
Если так, должны ли они быть переоценены? На мой взгляд, работа над этими пользовательскими историями может быть минимальной или много? Если нет, то почему нет?
РЕДАКТИРОВАТЬ: В моем конкретном случае истории не были завершены из-за препятствия, которое длилось несколько дней, а не из-за недооценки пользовательской истории. Для тех из вас, кто может помочь, мы используемVersionOne
Ответы:
Это зависит. Если ни одна другая история не имеет более высокого приоритета, то да, они переносятся в следующий спринт. Если другие истории имеют более высокий приоритет, они могут быть перенесены обратно в очередь продукта, если в спринте недостаточно места для их размещения. Все это происходит при планировании спринта на основе приоритетов, назначенных для каждой истории вашим владельцем продукта. Поскольку одной из целей гибких методов, таких как Scrum, является максимизация доставленной ценности при одновременном сокращении времени, все сводится к тому, сколько добавленной стоимости вы получите, закончив эти истории.
Независимо от того, что произойдет, вам все равно нужно стремиться к потенциально доставляемому продукту в конце спринта. Это может означать откат, чтобы гарантировать, что продукт конца спринта пройдет все тесты и завершенные функции будут полностью использованы пользователем без каких-либо значительных проблем.
Я бы не стал переоценивать, потому что в Scrum вы оцениваете историю, когда принимаете ее, начинаете работу, и у вас нет концепции частично завершенной . История либо на 100% завершена, проверена и принята (выполнена), либо еще не завершена. Если нет понятия частично завершенного, вы не сможете определить, сколько работы осталось в истории. Похоже, я тоже не одинок в этой мысли . Вы оценили работу, которую, по вашему мнению, вы можете сделать, поэтому оставьте эти данные в точке и обсудите, почему оценка была отклонена в вашем посмертном спринте, и постарайтесь избежать этой ошибки для будущих спринтов.
источник
Как правило, именно избранный Scrum-мастер решает, что делать с задачами, которые вышли за рамки спринта, очевидно, после консультации с остальной командой и спонсором проекта / владельцем продукта. В конце спринта самое время пересмотреть приоритеты. Возможно, что рассматриваемая история имеет меньший приоритет, чем новая / существующая история, и ее следует вернуть на трекер как «текущий» или любой другой ярлык, который использует ваш трекер, указывая на то, что за этой историей следует следить в другой момент. во время. В качестве альтернативы история может быть полностью удалена. Вы не упомянули, какой трекер вы используете, но большинство из тех, что я видел, позволяют вам установить историю как «удаленную», если она больше не является частью проекта.
Во-вторых, поскольку ваша команда является новичком в Scrum, это все часть процесса обучения. Теперь вы поняли, что некоторые истории слишком велики, поэтому вашей команде понадобится больше времени, чтобы разбить истории. Как правило, ответственность за то, чтобы это произошло, лежит на мастере схватки. Скрам-мастер также должен будет проконсультироваться со спонсором проекта / владельцем продукта с неполными историями, чтобы попытаться разбить их дальше или получить окончательное решение о том, как полностью их удалить.
В моей команде новый мастер Скрама избирается каждые 2 недели (спринт), поэтому каждый получает возможность управлять задачами, организовывать встречи Скрам и следить за тем, чтобы каждый представлял отчеты о проделанной работе. Я надеюсь, что это так в вашей собственной команде, это, безусловно, хороший опыт.
источник