У нас есть заниженная история, которая была завершена в разработке, но во время тестирования выявила проблему. При расследовании проблемы было обнаружено, что для исправления потребуется внешняя сторона. Внешняя сторона не предоставит это исправление до окончания спринта. Таким образом, наша история заблокирована до тех пор, пока внешняя сторона не предоставит свое исправление.
Благодаря необходимому стороннему исправлению у вас теперь есть предварительное условие для вашей истории (которое вы предполагали с самого начала, но оказалось, что это не так).
Вы должны вернуть историю в бэклог в конце спринта. Это не сделано. Поместите ли вы его в следующий спринт, зависит от правил вашей команды, но я бы не стал этого делать, если предварительное условие не будет проверено и подтверждено до начала спринта .
Спринт должен быть заполнен элементами, чтобы команда думала, что сможет выполнить это количество в конце спринта. Если неясно, может ли предварительное условие быть выполнено во время спринта, это даже не должно быть темой на совещании по планированию, кроме как сказать «предварительные условия недоступны? Хорошо, СЛЕДУЮЩИЙ». Спринт должен быть заполнен только теми задачами, которые команда может выполнить.
Как всегда, могут применяться исключения. Новым элементом невыполненной работы для следующего спринта может быть «проверить, не исправлена ли ошибка в выпуске 1.2.3, который выйдет во вторник». Это можно сделать, даже несмотря на то, что результатом «готово» истории может быть «она все еще содержит ошибки, мы не можем продолжить исходную историю в следующем спринте».
Это отличный вопрос и возможность узнать! Да, поместите Заблокированную Историю в Бэклог Продукта , если у вас есть замена аналогичного размера, и на следующей Ретроспективе обсудите:
Что это говорит о нашей Оценке и Определении Готовности ?
Если эта история разблокируется до окончания спринта, может ли она и/или должна быть завершена до замены истории?
Кроме того, с помощью Канбана вы можете вставить «заблокированную ячейку» в каждый столбец WIP (заблокированный элемент не должен учитываться в вашем номере WIP), и эта история автоматически станет элементом с наивысшим приоритетом, когда она станет разблокированной.
Я также утверждаю, что такие вещи должны каким-то образом отслеживаться командой как «внешние задержки». (Независимо от «названия схватки» для этого понятия.) Каждый раз (!) когда команда зацикливается, чтобы спланировать свой следующий «спринт», она должна явно проверять статус всех этих элементов, чтобы привлечь внимание руководства к вопрос (и последствия этого для всего проекта). Не просто упоминайте об этом в своем отчете по проекту — кому-то [другому], это пункт действия .
Руководству необходимо знать – и знать своевременно , – что подобные вещи происходят, особенно если это происходит неоднократно. Считайте долгом своей команды уведомить их и держать их в курсе.
«Вот почему».
На мой взгляд, они представляют собой функциональные зависимости, существующие между «проектом, над которым работает ваша команда» и «другими проектами, к которым вы не имеете никакого отношения». Это то, что определяет «критический путь» на уровне организации или даже предприятия . Они могут легко представлять проблемы с развертыванием и/или эксплуатацией, когда ваш проект «запускается». Хотя сами по себе они не являются «вашей заботой», они должны быть явно распознаны и отслежены как внутри вашего проекта, так и [намного?] над ним.
Тодд А. Джейкобс