QA:As responsible for the product quality, I do not approve the release. It’s notworking properly on Internet Explorer 7.0.
Product Owner:As responsible for maximizing the product value, I approve to go live NOW! This is no blocker at all. Also, we don’t have clients using this outdated browser.
QA:We have to cover Internet Explorer; it’s part of our browser matrix. So, no go-live is happening until the compatibility problem is fixed.
Product Owner:It makes no sense. We need to review the browsers you are testing based on our REAL audience. Otherwise, we waste our time. But for now, the go-live must happen!
This is a typical situation between QAs and Product Owners. Although the Product Owner and QA are in thesame team and share the same objectives, the tension between them is getting higher and higher, yet, the discussion is leading nowhere. How could we avoid such disputes? How could we collaborate more?
During my journey as a Product Owner, I have found some alternatives to approach this situation. Let’s explore them.
The QA role within the Scrum Team
Before we jump into alternatives for a healthier relationship between Product Owners and QA, let’s understand how it works with Scrum.
The Scrum framework is suitable for any business. Therefore, QA, Tester, UX, UI, and someother roles are not part of Scrum because it would be limiting. However, Scrum says developers bring all required skills to achieve the product goals.
In short, developers are responsible for every activity required to build a product.The members have no titles.In this case, QA is an activity inside the team, not a role.A specific team member may perform it. However, the team is accountable as a whole.
Despite the clarity in the Scrum Guide within the team’s structure, companies often use titles for each team member, which blocks teams from functioning as optimal as they should.
The misunderstandings about testing
Picture this scenario, during the retrospective; the Product Owner raised a concern “Why do we take so long to test each Product Backlog Item? I feel that we are overcomplicating our work instead of simplifying it. We continuously carry over items due to the QA process.”
Each Sprint, the Scrum team, commits to a Scrum team, which means all work must happen inside the Sprint. Regardless if members have a title as QA or not, in the end, the accountability goes to the whole team. So testing methods and approaches are part of developers’ responsibilities.
The team’s Definition of Done (DoD) sets the granularity of testing. However, developers oftendefine the details without involving the Product Owner.That’s when many problems start because it creates a mismatch of expectations between the Product Owner and developers.
The DoD defineswhat “Done” means for the entire Scrum Team. So all members should play a part in crafting the DoD. The Scrum Team should aim for simplicity so that the team avoids waste.The Product Owner should collaborate with the developers to agree upon a quality level. For example, in an online shop, which browsers do we support? That should be clear; otherwise, misunderstandings are inevitable. So, expectations matter a lot.
Clear expectations on product quality are vital for an efficient Scrum Team. Without it, the team needs to guess what quality means, which leads to inefficiency.
How should the team test the Product Backlog Items?
In Scrum, developers present Sprint’s result during the Sprint Review, the Product Owner and the invited Stakeholders attend the event. However, the practice doesn’t go so often hand in hand with the theory.
A typical scenario is the Product Owner provides feedback to developers during the Sprint. For example, once a developer finishes a feature, she asks the Product Owner for validation. However, in this case,when should the Product Owner provide feedback?
Recommended by LinkedIn
I’ve seen different scenarios:
An excellent Product Owner will encourage developers to make decisions without her input, which does not mean the Product Owner should be absent. A highly collaborative Product Owner whocoaches teams to solve problems in real-time in the Sprint builds a strong team. High-performing teams have this characteristic.
Who has the final word on Go-live?
Before answering the question, let me walk you through a situation I lived in. Developers had just presented Sprint’s result. Then a conversation started.
Product Owner:Great! I’m happy with the result, so can we Go-live at the beginning of next week?
Dev:Not sure. We still need to test on some devices and browsers to ensure it works as it should.
Product Owner:Hum.I thought the tests were part of the DoD. What is missing here?
Dev:Well, we tested already, but we want to test a bit more. For example, on Kindle, it was not so good.
Product Owner:What? Kindle? Why are we testing on Kindle? Let’s Go-live. We do not need to waste our time checking on this device. Our audience does not use Kindle.
This exchange may seem like a joke, but developers didn’t want to release the new features because it was failing on Kindle, even though we had no clients using this device. At this moment, I learned the importance ofsetting clear quality expectations across the entire Scrum team.
But if we need to decide on Go-live, who can do it? The Product Owner.BecausetheProduct Owner is accountable for maximizing the product value.However,this is bestservedthrough a collaborative decision-making process versus the Product Owner unilaterally deciding without building understanding.
Some companies have aseparate QA team.This scenario creates a hand-off between the Scrum Team and the QA team, which negatively impacts flow andreduces the team’s control in getting to done.In this case,both teams should define the DoD together. When deciding on Go-Live, theProduct Owner is ultimately accountable for that. Still,collaboration among the teams will lead to better results.
Increasing the collaboration inside Scrum Teams
A great way ofcollaborating is by having informal talks. As a Product Owner, whenever I have an idea,I invite a couple of developers to have a coffee. Generally,I like talking to someone deeper on the development andanother more knowledgeable on quality assurance.I aim to getdifferent perspectives on my idea so that we can make it better.This approach is also known as theThree Amigos.
Three amigosrefers to the primary perspectives to examine an increment of work before, during, and after development.Those perspectives are: Business — What problem are we trying to solve? Development — How might we build a solution to solve that problem? Testing — What about this, what could possibly happen? —Agile Alliance
Once I started using the Three Amigos approach,we could discover better alternatives from the very beginning. This approach is helpful; it increases the feedback loop and improves flow.The Three Amigoshelps to get perspectives and evaluate possibilities so that team can decide whether it makes sense or not to pursue the idea.
Wrap-Up
Quality Assurance is a discipline in software development. However,it is not a role in Scrum.Yet, Scrum Teams should have all the required skills to reach their goals.How can a Product Owner help the team to be more efficient in terms of quality assurance:
