Прошу прощения за поздний ответ. Самое важное в такой ситуации - понять почему так вышло. Для этого и нужна ретроспектива. Причины в каждом конкретном случае могут быть разными. Например, команда могла недостаточно вникнуть в некоторые задачи и дать им слишком маленькую оценку. В такой ситуации имеет смысл подумать о более детальной декомпозиции задач. Или во время спринта пришло слишком много критических багов, команда потратила много времени на их починку, и заложенного в фокус-фактор запаса не хватило. В такой ситуации имеет смысл заложить больше времени на починку багов в фокус-фактор или начать разделять баги на приоритетные и неприоритетные. Может статься, что заболел сотрудник, который знал некие важные детали решения одной из задач, и без него разработка решения заняла гораздо больше времени, чем планировалось. В этом случае имеет смысл обсудить способы распространения знаний внутри команды. Единственный точно работающий совет - обсудите это внутри команды на ретроспективе и постарайтесь предотвратить повторение в будущем. С первого раза может не получиться, и это нормально :) Просто продолжайте улучшать процессы с каждой итерацией.

Это должно зависеть от команды. Один из основных моментов скрама в том, что команда в состоянии самостоятельно организовываться для решения проблем. Я вижу несколько стратегий выхода из таких ситуаций. 1) Баги не критические. Они добавляются в бэклог с высоким приоритетом, и в следующий спринт (через одну-две недели) команда занимается ими как обычными задачами. 2) Есть несколько критических багов, которые нужно исправить прямо сейчас. Эти баги помещаются в текущий спринт с высшим приоритетом, и решаются по мере освобождения разработчиков от других задач, остальные баги помещаются в бэклог как в варианте 1. За счет того, что в планирование включен фокус-фактор, обычные задачи спринта не особенно страдают от дополнительной работы по исправлению багов. Мы в команде работали именно по этому варианту. 3) Баги уровня "конец света". Баги помещаются в бэклог, текущий спринт останавливается, выполняется планирование и запуск нового спринта, в который включаются найденные критические баги. Стратегия 2 сочетает плюсы остальных, так что я рекомендовал бы начинать с нее. Самое важное - обязательно обсудить на ретроспективе как сработала стратегия починки внезапно обнаруженных багов и внести исправления в процесс, если требуется. В следующий раз следует использовать исправленную стратегию, снова обсудить и подправить, и так далее. После нескольких итераций команда найдет оптимальный вариант.

спасибо большое за столь развёрнутый ответ!

Презентация: drive.google.com/open?id=0BwdVys-FnlwLZGVjMHJLNU0xNFU