Но денег съест как надо)

Да так что рукли задумаются)

Почему?

Ну в толпе легче не работать, чем работать)

За готовыми ответами — к Григорию Остеру, отцу деврелов

Тут @vfabr большой фанат построения целеустремлённых систем. Мне что-то подсказывает, что таблица - это такой хардкод, когда гвоздями прибивают то, что должно автоматически решаться процессами такой вот системы.

Да, он мне уже пояснил за это говно, которое у нас образовалось

Как переубедить начальство, не подскажу, но начни с того, что просто эту таблицу представь в виде диаграммы ганта. Это именно она, спрятанная в таблицу.

Спасибо. Почитаю

Смотри. У вас попытались внедрить скрам, но не смогли сделать этого до конца.
Спринты возможны при наличии следующий условий:
1. никого не волнует скорость запуска фичи (минимум три спринта)
2. все разработчики - универсалы (нет фронтендеров-бэкендеров-qa)
3. нет зависимости между задачами внутри спринта
4. все задачи похожи друг на друга (для соответствия скрамгайду не обязательно, но фактически всегда требуется)
Если хотя бы одно из этих требований не выполняется, то получится фигня. У вас, подозреваю, не выполняются все четыре пункта.
Нужно или реализовывать требования скрама или плюнуть на него и строить подходящую под ваши задачи методологию или искать нормальную работу. Последнее - наиболее реалистичный план.

Конкретно в вашей ситуации можно сделать следующее
1) Разделять разработку и тестирование по разным спринтам.
Т.е. разработчик делает фичу, делает предварительное тестирование и юнит-тесты, показывает на демо.
QA прогоняет полноценное тестирование в следующем спринте и делает уже демо чистовой версии (заодно проблемы, выявленные на демо исправят).
2) Перейти от ручных проверок к автотестам, которые пишут разработчики. И к contract-first подходу. Тогда QA могут начать тестирование фичи до ее реализации. Но это требует стадию анализа и проектирования фичи, которую придется вынести в отдельный спринт от разработки.
3) Посадить (хотя бы на часть времени) QA и разработчика за один компьютер, пусть вместе тестируют и пишут тесты в рамках реализации одной фичи. Velocity считать по факту.
4) Запрещать в планировании брать в работу задачи больше 4 человеко-часов, каждая задача должна тестироваться независимо.
Тогда и в текущем подходе будете помещаться в спринт.

Можно брать любые из этих 4 пунктов и как-то смешивать.

1. Волнует всегда скорость фичи.
2. Четкое разделение На клиентских разработчиков и серверных
3. Бывают и очень часто. Ещё одна особенность, что много задач на сервере не пересекаются с клиентским кодом.
4. Задачи очень разные попадают. Т.е. начиная с какой-то частью аналитики и заканчивая рефакторингом сервиса, к которому отношения не имею от слова совсем. У клиентских разработчиков проще. Там всегда задачи в одном скоупе, но отличаются

Ни один пункт не верен :)

Не только фанат, но ещё немного и эксперт 🥸

А доклады есть?

Определить бы людям что такое "велосити" 😅

Ну, вот потому все и выглядит ужасно.

крунпый город, хорошо приспособленный для велосипедов

Толку с докладов, за них никто не платит 🤷

Звучит интересно , что-нибудь попытаюсь внедрить