Product owner decides the priority.
The reality of test management is often FAR more complex than it initially appears. Multiple factors contribute to inefficiencies, miscommunications, and challenges in maintaining a streamlined workflow. This is what we see a lot:
For example, Jira is widely used, but the Severity field is frequently filled out ambiguously, leading to confusion. Similarly, the Priority field is often misused, creating inconsistencies in task prioritization (this is not the fault of Jira they provide everything to do it right). It remains unclear who holds the authority to populate these fields or who should be responsible for adjusting them. Additionally, there is a lack of clarity on how set priorities should be reviewed and by whom. It's simple: You need to know what needs to be tested!
A visual representation of a Grok-generated clip used to determine priorities in such chaos projects.
A Product Risk Assessment (PRA) (or similar product-risk-context-related evaluations) are not always conducted, or they are performed incorrectly. Next to that unforeseen bugs can demand significantly more testing effort than what was estimated during sprint planning sessions. (if test effort was even ♣pokered♠ (estimated) at all)
Senior stakeholders often exert pressure on team members, insisting that their requests be prioritized ahead of schedule, even when this disrupts the planned sprint. These tasks typically lack proper effort estimation but are addressed nonetheless. As a result, they are often inadequately tested, and test automation is not developed in time.
Tasks slotted in on an ad-hoc basis frequently go unnoticed, slipping under the radar. This does not diminish the need for thorough testing or test automation, yet these critical steps are often overlooked, compromising overall quality.
Opens the planning secrets page in a new tab.