Гибкое планирование выпуска релизов 101 (на основе Excel)

NeverIn вам этот комментарий нужно оставить на английском языке в блоге Tommy Norman-а.

А багами занимается отдельная команда?

В оригинальной статье говорится что багами занимается та же самая команда. Автор говорит что чаще встречает два варианта.

Первый — что кто-то из разработчиков узнаёт что это «его» (он разрабатывал то, что выдаёт ошибку) и забирает этот баг в свой персональный список, выделяя на их устранение определенное количество времени на цикл разработки (Sprint).

Второй — что они добавляются в общей список (Product Backlog) и команда тратит общее время на цикл разработки, чтобы устранить те из них, чтобы были добавлены в Sprint Backlog.

По какому принципу оценивается estimate бага?

Если баги добавляются в Product Backlog также как User Story в момент старта, когда Product Backlog-а ещё нет, то в этом случае оценка будет происходить по тем же принципам что и весь список. Сперва: smal, medium, big. Затем уже используются цифровые оценки.

Если баги будут появляться в ходе каждой итерации и добавляться в персональные списки, то затраты на их устранение оцениваться не будут, а оценивается только степень критичности бага.
Если баги будут добавляться в Product Backlog, то оцениваются в единицах трудоемкости той системы координат, которую выбрала команда для Product Backlog-а.

На что Автор обращает особое внимание, что те с кем ему доводилось работать сперва настаивали на том, чтобы проанализировать баг, чтобы понять что не так, перед тем как давать какую-то оценку.