Классическая проблема канбан-досок в разработке (upd речь о scrum и его доске спринта)— необходимость передать задачу в QA. Вот взял разработчик задачку в первом столбце бэклога, перевёл в столбец разработки, пожёг стори-поинты, а передвинуть в релиз не может. Задача уходит в столбец “Ready for QA” и висит там в очереди, иногда днями. Велосити страдает, сторипоинты не сгорают, не происходит вообще ничего. Дальше QA вынимает задачу из очереди, переводит на себя, тестирует неизвестно сколько (никто же не закладывает сторипоинты на тестирование), по итогам либо возвращает в разработку либо переводит в “Ready to merge” что и даёт возможность запустить автоматику релиза.

И как из этого всего делать аналитику? Вся красота системы ломается об бутылочное горлышко QA, да и в принципе система не работает, если движение задачи зависит больше, чем от одного человека. А ещё и веточки с задачами висят больше одного дня и никак не могут попасть в main, что прямо совсем несовременно и плохо.

И никто в целом мире не придумал, как эту проблему решить и заставить чудесный Agile Sprint работать, вот так вот, чтобы сколько напланировали — столько и сделали, и бёрндаун такой под 45 градусов вниз летел как паровоз, от спринта к спринту всё быстрей и мощней.

Единственное решение, которое мне кажется более-менее жизнеспособным — это убирать из процесса доставки задачи до релиза QA целиком и заменять его автоматикой. Разработчик пусть сам пишет автотесты для своей задачи по предоставленным QA сценариям, а QA достаточно валидировать их качество и заниматься общим набором E2E, гоняемым предрелизной автоматикой. Вот только в этом случае появится какая-то предсказуемость в оценке срока доставки задач.

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