Как уложить тестирование фичи внутрь спринта?⁠⁠

Когда команда с горем пополам научилась попадать с разработкой запланированного внутрь спринта, то встает следующий вопрос - а почему мы все равно не успеваем впихнуть то, что уже было разработано в релиз после спринта?

У нас именно так и получилось. Вначале разработчики не использовали никакой системы при планировании спринта - это было больше похоже на индивидуальное планирование, каждый брал себе столько сколько сможет унести, и конечно результат спринта был достаточно рандомным. Что конечно расстраивало заказчиков, никто не понимал - когда же будет доставка конкретной фичи?

После внедрения poker planning и story points, ситуация с прогнозированием разработки улучшилась значительно. Но заказчики (Product Managers в нашем случае) инстинктивно воспринимали завершение разработки как готовность фичи. Это конечно было ошибочное ожидание, более того, когда PM смотрели на каждую фичу и видели:

Фича A -> 3 Story Points

Фича B -> 8 Story points

То ошибочно думали, что тестирование будет занимать пропорциональное количество времени, то есть например:

Фича A -> 1 день?

Фича B -> 2 дня?

Но в реальности объем тестирования никак не был связан с Dev Effort по разработке конкретной фичи. Все могло быть с точностью до наоборот:

Фича A -> 3 дня

Фича B -> 1 день

Дело в том, что тестирование очень часто находит ошибки в новой фиче, что вызывает еще один цикл исправлений (дополнительный Dev Effort), и еще один цикл тестирования/перетестирования. И чем больше объем тестирования конкретной фичи, тем дольше цикл перетестирования. А чем более сложная фича (не равно емкости Dev Effort), тем больше циклов исправлений и перетестирования ожидается.

Можно предложить укладывать циклы тестирования и перетестирования в изначальный Dev Effort в Story Points, но Capacity команды Тестирования не входит в команду Dev, поэтому так не получится.

Поэтому мы решили попробовать следующий подход. Команда тестирования на стадии прототипирования фичи (до начала разработки), пишет предварительные тесты для покрытия этой фичи, и должна давать отдельную оценку Test Effort, включающую риски по возможным багам, и их переработкой.

Чтобы эту оценку не путать и не складывать с Dev Effort, мы решили сделать ее не цифровой, а символьной, в размерах маек S, M, L, XL.

Мы долго думали, должна ли шкала оценки быть нелинейной (фибоначи например), как Dev Effort в Story Points. И решили, что в этом не необходимости. Дело в том, что заказчик (PM), хочет знать, когда он получит фичу в Прод, и при планировании спринта у него есть выбор, состоящий из Dev Effort и Test Effort, который либо "влазит" в спринт, либо нет. Тогда при планировании сразу понятно, что с большой вероятностью будет доставлена, а что потребует больше одного спринта.

Получилась вот такая схема:

То есть, чтобы впихнуть L фичу, надо отдать ее тестировщикам в конце первой недели спринта. Для M, S во вторник, четверг второй недели соотеcтвенно. Для XL зарелизить в рамках одного спринта шансов нет!

А как у Вас с этой проблемой?