Ответ
В командах, где я работал, процесс определения приоритета дефекта был совместным. Severity (серьезность с технической точки зрения) я, как QA, указывал сразу при создании баг-репорта. Priority (приоритет для бизнеса) окончательно выставлялся на ежедневном стендапе или планировании спринта после обсуждения с Product Owner и Tech Lead.
Например, баг с Severity: Critical (падает весь сервис) мог получить Priority: Medium, если он проявлялся в сценарии, не планируемом к использованию в ближайшем релизе. Для прозрачности мы использовали метки в Jira:
[Severity] S1 - Blocker
[Priority] P2 - High (Must be fixed before the next release)Такой подход позволял балансировать между техническим долгом и бизнес-ценностью.
