Why you need both a QA and PO in your team

In my experience, the more synergistic the relationship I have with the POs (Product Owners), the better I can do my job as a QA (Quality Assurance). Of course, the relationship with the developers is also crucial, but here I want to specifically show how projects can obtain more success when QAs and POs work as a team.

Product Owner’s work is only complete when the QA’s work is complete

It means that their work is complementary. At ZRP, POs are responsible for requirements elicitation, project management, and interfacing between the agile team — me, designers, and developers — and stakeholders. So, whenever anyone has doubts about a user story, for example, we resort to the PO. From the QA perspective, I usually read and analyze each user story opened and written by the PO a week before the sprint planning.

Therefore, I can investigate if all the information I’ll need for testing is available and if it is coherent. We call it “Pre Sprint”, which means that we are always a sprint ahead in terms of user story prioritization, design, and technical approval by the developers.

We created this “Pre Sprint” process to avoid:

• Starting to implement awasn’t User Story without the design: modifications in the design when the sprint is running can delay the sprint. The solution was to establish that if the design isn’t ready, the user story wasn’t ready to enter the sprint. We also can detect if the designer is facing problems in projecting a screen because of the lack of information given by the POs;
• Lack of information inout the user story documentation: everyone analyzes the documentation to verify its completeness. However, one of the values in the agile manifesto comprehends “Working software over comprehensive documentation”. We can’t put time and costs at risk by misunderstanding this agile value. We respond to changes, but we only can do it with wisdom. Important information and acceptance criteria must be documented so the team can read it and point out what isn’t clear, or poorly defined. At this moment, the PO must be available to hear this feedbackelicit and work to complete the documentation;

QAs also elicit requirements

QAs are responsible for a wide variety of tasks during a sprint, but they are also the first ones to use the software product. QAs are the “first users”! Looking from this perspective, the QAs will make the same questions a user could make, for example:

• Do I have any difficulties using the software?
• What could be improved?
• Are the information and functionality flow confusing?

The answers to these questions like the ones above can result in new enhancements, or even new user stories. POs are the most qualified persons for the QA to communicate their considerations. Together, they will explore it more deeply and transform ideas into solutions of value, that later the POs can aggregate into the product backlog.

POs are an oracle (or almost)

Although we follow the “Pre Sprint” format, or any preventive actions to make the sprint backlog ready to be developed, other details can emerge. POs are decisive to treat it as fast as they can to avoid delays. We consult POs as if they are oracles (or almost).

For example, while the QA writes a test scenario, new doubts and observations can emerge about business rules or acceptance criteria. QAs can resolve all of it with POs’ crucial help. At the same time, POs can validate if those test scenarios cover the most important and risky rules.

Small stories

When I read a story for the first time, as a QA, I can detect its complexity/size in terms of:

• Main flow;
• Possible alternative and exception flows;
• Number of fields to validate;
• Possible impacts on stories already delivered.

If I consider the story too big, I can share it with the PO, so we can negotiate and split it into more stories/issues before the story enters the sprint. Make sure all stories are tiny so the design, implementation, and tests are easier to track.

The bigger the story is, the later it will be shipped to the test environment. Smaller time to test means smaller chances to achieve quality.

Conclusion

This post was thought to show the high potential of the relation PO-QA. Remember: quality is a product aspect. Therefore, every team member is responsible for maintaining the quality culture, with the assistance of the QA and the PO.