Небольшой список правил и вещей, которые помогут вести проект Releases правильно и приоритизировать задачи.
Прописать все задачи в формате User Stories: "Я, как пользователь, хочу иметь возможность делать что-то для чего-то"
Все задачи для реализации конкретной User Stories должны быть прописаны в под-задачи этой User Stories. То есть, все задачи: Frontend (Web, Mobile), Backend, Design - не важно. Всё для реализации этой User Stories.
В предcтоящий релиз вносятся только самые приоритетные User Stories
Все задачи для реализации самых приоритетных User Stories должны быть оценены (хотя бы на предстоящий релиз)
Самые приоритетные задачи (то есть, под-задачи) для реализации самых приоритетных User Stories должны быть в нынешнем спринте. Тем самым, мы видим над каким именно функционалом работает каждый инженер.
Как идёт нумерация релиза? Например, 4.1.2. Первая цифра "4" - это большой релиз большого функционала (например, релиз Medcheck ID). Вторая цифра "1" - это улучшение существующего функционала (например, добавление экстренных контактов в Medcheck ID). Третья цифра "2" - это исправление багов, мелких ошибок, опечаток и любые мелкие задачи (например, исправление текста в статье, исправление расположение текста по центру).
У каждой задачи должен быть проставлен тэг: Frontend, Backend, Design, Infra, Flutter, Sign In, Sign Out, Transactions и т.д. - то есть, мы тэгаем задачи по технологиям и по функционалу
Релиз нужно делать еженедельно, или, как минимум, стараться делать их еженедельно. Даже если ты просто исправил один пробел или небольшой текст - выпускайте релиз. Команда должна привыкать выпускать апдейты еженедельно.
Каждый релиз должен иметь своё название и чёткий Release Note.