Не забывайте об ограничении системы
Допустим приемочное тестирование – это ваше самое узкое место. Например, у вас слишком мало тестировщиков или фаза приемочного тестирования забирает много времени из-за ужасного качества кода. Допустим, команда, которая выполняет приемочное тестирование, успевает проверить 3 фичи в неделю (не подумайте, мы не используем "фичи в неделю" как метрику; я взял это для примера). Также допустим, что ваши разработчики могут сделать 6 новых фич в неделю. Для менеджера или product owner'а (даже для самой команды) будет искушением запланировать разработку 6-ти новых фич в неделю. Только не это! Витать в облаках долго не получится, а когда упадёте – будет больно. Лучше при планировании рассчитывать на 3 фичи в неделю, а оставшееся время направить на устранение узкого места. Например:
- Заставить разработчиков потестировать (приготовьтесь к "благодарности" за это...).
Внедрить новые инструменты и скрипты, которые упростят тестирование.
Добавить больше автоматизации.
Сделать длиннее спринт и включить приемочное тестирование в спринт.
Выделить несколько "тестовых спринтов", где вся команда будет работать над приемочным тестированием.
Нанять больше тестировщиков (даже если это означает уволить некоторых разработчиков).
Мы пробовали все эти решения (кроме последнего). С точки зрения долгосрочной перспективы лучшими являются пункты 2 и 3, а именно: более эффективные инструменты, скрипты и автоматизация тестирования.
А для выявления узких мест лучше всего подходят ретроспективы.