Scrum challenges with Developers and QA. Seeking suggestions.

Over the past three to four years, our organization has been working to enhance our Agile practices. While this journey has had its ups and downs, it has given us value to be more iterative.

First, I would like to provide some context to better understand the situation. I am part of the IT software development leadership team, and my software engineering teams are all organized into scrum teams, consisting of a Product Owner, Analysts, Scrum Master, Developers, and Quality Assurance specialists. Our sprint cycles are two weeks long. Engineers work on a feature branch and deploy it to a DEV environment where it is tested with other features. The engineers then promote the changes to our QA environment where the QA testers will perform their testing.

One of the recurring challenges brought to my attention is that during the two-week sprint, the developers consume most of the sprint on feature development, leaving limited time towards the end of the sprint for the Quality Assurance team to conduct their testing. I decided to sit in on a grooming session with one of the teams that have these challenges and one of the things I observed was that the PO was grooming tickets with a large number of acceptance criteria (8 – 12 bullet points of criteria for the ticket to be marked as complete). I asked the PO if she could refine that ticket into smaller workable user stories so the developers could deliver smaller features over to QA as soon as they complete the user story's feature.

I have engaged in discussions with several IT stakeholders and the following are some of the outcomes of those discussions. I would be grateful for feedback from others who have selected any of the potential options listed below for their own use and how it has worked out for their scrum teams.

*** Option 1 **\*

Implement a Shift-Left Approach for the Quality Assurance (QA) Team. This approach would involve the QA engineer starting the testing process early in the software development cycle, potentially testing in the feature branch or the development environment. As a result, the QA team would not have to wait until the code is promoted to the QA environment. Additionally, the QA team would be working closely with the developers from the outset, potentially assisting in the creation of automated unit tests for the feature.

​

*** Option 2 **\*

Instead of shifting left with option 1, ensure the team is refining the user stories small enough so the developers can work on smaller features (ones that might take only a 1 to 2 days) and quickly promoting those features into the QA environment for QA to begin testing as early as day 3.

*** Option 3 **\*

Option 1 & 2 – Refine User Stories and Implement a Shift-Left Approach for the Quality Assurance (QA) Team. The objective of this combined approach is to break down user stories into smaller, manageable features that can be completed within 1 to 2 days by the developers. At the same time, the QA team would start testing the features early in the software development cycle, either directly from the developer's feature branch or in the development environment, rather than waiting for the code to be promoted to the QA environment.

In Summary

The only concern with shifting left for us is that I understand that to shift left, you need to practice automated testing as much as possible, and implementing TDD would also be helpful. Otherwise, your QA is going to be spending a lot of time manually validating in several places (feature branch, DEV environment, and the QA environment).