How to better incorporate QA into Agile planning

The biggest problem for software development teams is getting work done under time constraints. 54% of development teams are struggling to keep up with software delivery. Product teams wanted it yesterday, and devs can’t deliver until tomorrow. 

No development team wants to release code that is buggy; however, timelines and commitments will sometimes be determined prior to the engineering team scoping out the new feature or product. Sometimes, the market determines the timeline or, if there is no timeframe, the engineering team will scope out the feature or product and set the ideal timeline. There is always a balance here. In the latter situation, you could face the scenario of perfection killing progress and be late to market. In the former, the time constraint pressure can intensify even further.

Regardless of the scenario you find yourself in, not including QA will set you back even more as testing is essential to the success of your product. Building a better agile process with QA begins with focusing on minimum viable features, pushing code like a factory line, and incorporating QA into the grooming process.

Start with minimum viable features

The constant tension between software dev speed and quality can inadvertently gloss over profit. A 12-month planning cycle that covers every possible product feature means a year of lost revenue before the building even starts. Instead, focus on collaborating with product owners and product managers to finalize a list of minimum features that the product needs to be viable.

As you determine the scope of minimum viability, start to create a backlog of features to build a second and third tier of features. If your team makes outstanding progress and starts cranking out work, you can bring in more features from the backlog until you complete the larger product goals.

During the planning phase, break out each essential feature individually and:

•  size it
• create acceptance criteria
• define the definition of done
• create QA guidelines that cover functionality, types of devices, browers, etc., so developers can commit code to the QA branch, or similar, and the QA/testers can test once the feature reaches QA.

In a perfect agile process, devs and testers are aligned on sprint goals and feature quality. By incorporating QA earlier to make quality a priority, features are less likely to stall at the QA stage and can smoothly advance like a factory line.

Push code like a factory line

Starting with minimum viable features gets developers approaching projects with a focus on small features rather than the entire product. That focus sets up agile teams to quickly commit code in smaller chunks through the pipeline. If you build huge pieces of code and ship them to QA, and that large piece fails integration tests, you could build bottlenecks with too many features stalling at QA at the same time. Start with smaller pieces of code based on test-driven development. Build out the test first, write the minimum amount of code needed for that test to pass, and push it off to the next phase. 

Build small chunks of code, get it to QA in good shape, make sure the test passes, and then move on to the next chunk of code.

This type of rapid code development means continuing the pattern of breaking down individual features into smaller increments during the planning phase. A sprint task that sounds relatively simple, like building a login page, has a deceptive amount of work to be outlined and assigned. What kind of login steps or authentication is required, and what does the flow look like for the user? Though the breakdown takes time up-front, the sprint cycle goes quicker. Shipping smaller chunks of code mean that QA can test and pass code quicker and avoid bottlenecks.

Finally, communication between devs and QA has to start before the build process begins. If the factory pipeline is unclear, devs don’t know where they are pushing code to or what minimum viability looks like for QA. Dev teams want to finish their code, commit it and move on, while QA wants to dive into more complex testing to find bugs. If QA is spending too much time testing basic functionality, not only could they miss critical bugs, but dev teams are left waiting on feedback and the pipeline grinds to a halt.

Incorporate QA into the Agile grooming process

Similar to shift left practices in testing, dev teams should incorporate QA and testers earlier in the planning and grooming process. By incorporating QA into the planning process, such as sprint planning, you will get valuable input on the functionality of your product and better acceptance criteria from your actual testers. 

If your QA/testers are on a different team, start by inviting them to the grooming process and creating an open dialogue between devs and QA. Agile best practices for dev teams are meant for the entire team, sometimes QA is left out of the process. Your QA members are a valuable resource for your dev teams and should be part of the process, especially when determining the complexity and effort, whether through estimation techniques like planning poker or T-Shirt sizing as well as documenting the acceptance criteria.

Agile teams need to break down silos in the SDLC to move forward without wasting time waiting on feedback. Hastening this feedback cycle starts by improving communication between teams, including incorporating QA into the Agile grooming process. The grooming process should define what QA will be looking for, minimize risks of complete QA failures, and protect dev time by outlining requirements before the work starts. Don’t wait until the sprint starts to begin this dialogue, it will slow down your teams. Start early, include QA, and watch your product’s quality become better, faster.