“Dev to QA handover” process improvement

Question

I would like to get some help or ideas to solve my problems, I just join a small company as junior project manager and I faced with 2 challenges sorry for my ignorance but I am new into the agile world.

1. QA has many tickets in each sprint that appear as “Ready for testing”. Some of them are indeed ready, while others - not at all. what can be the possible reasons for tasks to appear in the workflow as ready for QA, when they are actually not?

one of my thoughts is that the task goal isn't clear and simple which may cause gaps in the terms of "done" within the development to the QA team Please list other reasons from your experience.

2. I have been asked by the QA team lead to find a way for his team to recognize and sort out tasks that are not ready. The tool of task management for all teams is JIRA. What could be a possible solution (or solutions?).

I though about Adding news phases in the flow in order to reflect the precise status, "Ready for Dev" => “In Development” => “Code Review Requested” => “In Code review” => “Ready for Testing” => “In Testing” => Done

Do you have any other solutions ?

Answer 1

There are a couple of different problems happening here that may be intertwined.

Having a hand-off between a development team and a QA team is generally anti-agile. In order to achieve agility, teams often need to be self-organizing, cross-functional, and highly collaborative. Having a hand-off from a team that designs and builds the solution to a team that tests the solution may be indicative of a team that isn't cross-functional. Embedding the quality assurance and testing activities in one team can reduce uncertainties around the state of the work around these hand-offs since there is no more hand-off.

However, there may be good reasons to have an independent QA team. In these cases, having a clear understanding of the work is essential. The visualization of the workflow and the work in that workflow would be extremely beneficial for this. Adding and removing states to accurately reflect the reality of the workflow would be extremely beneficial to everyone involved in the process.

I'd also consider applying automation to your tool. For example, you mention Jira. Jira integrates with version control systems to allow for automatically transitioning issues. For example, I've worked with Jira and Bitbucket to automatically transition issues when branches are created, pull requests opened, and pull requests merged into specific branches. With the right transitions and integrations, you can also roll back if new branches or pull requests are made, changes are reverted, and so on. Jira can also integrate with CI servers to track deployments to various environments. All of this information can be available in the Jira UI and can make the state of the work more explicit.

Something that I've seen frequently by teams combining Scrum and Kanban is aligning the Definition of Done to states in the workflow. In order for work to transition from one state to another, there is a clear definition of "done". This helps to make sure that everyone understands what the state of the work is when it is moving into or out of a particular state.

I'd also suggest a retrospective. I'd want to make sure that the development teams understand the QA process and workflow and vice versa. Perhaps the people can identify pain points in the process and have solutions to fix it on their own. The best processes are often built by the people doing the work, with the right guidance and support.