Почему стоит записывать найденные дефекты в багтрекинг систему

До недавнего времени у нас методология разработки была waterfall и этот вопрос не поднимался. Но вот и до нас дотянулись руки agile методологий, в частности scrum'а. Некоторые инженеры по качеству перестали записывать найденные дефекты в багтрекер ограничиваясь бумажкой на scrum доске. Свой поступок они аргументируют так:

1. Зачем тратить лишнее время на запись - есть же бумажка на доске.
2. Скрам гибкий - я подошел к разработчику, показал проблему и он ее тут же исправил.

Мне кажется что такой подход будет работать в очень ограниченных случаях. Приведу свои доводы против этого:

1. На бумажке нельзя подробно описать условия и порядок действий для воспроизведения дефекта. Нельзя указать множество, на первый взгляд, мелких параметров - ОС, локаль, фича (история) при тестировании которой найден дефект, путь к логам продукта или дампам, снапшоты, номер билда на котором дефект воспроизвелся и т.д.
2. Ветер подул, вешали другую бумажку и сбили эту - бумажка упала с доски. Все баг потерян. Как не смешно звучит но у нас уже такое было :-)
3. Когда разработчик делает чекин кода после исправления дефекта он, обычно, хочет его связать с этим дефектом. Записанный в багтрекинг систему дефект идеально для этого подходит.
4. Иногда они возвращаются. Переоткрывая баг мы вместе с ним получаем его историю, в которой может быть описана причина – разобрались но исправлять не стали (низкий приоритет, потребуется много проверок в смежных модулях и т.д.), отложили и причина почему и т.д..
5. Имея багтрекинг систему мы получаем легкий способ снимать различные метрики – кол-во багов по историям, на тестерах, на разработчиках, скорость работы с багами, количество актуальных дефектов по приоритетам, как часто баг переводится между разработчиками и т.д.
6. Мы нашли дефект и радостно бежим к разработчику чтобы показать его, но он просит нас подождать часок - другой пока он закончит более высокоприоритетную задачу. Что нам остается делать - ждать или продолжать тестировать продукт дальше с шансом забыть тонкости воспроизведения найденного дефекта?
7. Сборка новой версии продукта иногда занимает часы и чтобы убедиться что дефект исправлен нам нужно ждать. За это время мы можем переключиться на другую задачу и забыть проверить наш дефект. Записанный в багтрекинг систему дефект всегда позволяет знать в какой версии продукта он исправлен и это также избавляет нас от необходимости помнить какие дефекты в каких версиях продукта надо проверять (я не ставлю под сомнение вопрос о том что окончательную проверку исправления дефекта нужно делать только на сборке продукта, никак не на модуле присланном разработчиком).
8. Поиск - перебирать бумажки с описанием дефектов менее приятно чем искать дефект в багтрекинг системе.

Мне кажется, что приведенных доводов достаточно для принятия решения о записи найденных дефектов в багтрекинг систему. Буду рад ответить на вопросы и выслушать замечания.