How Does QA Fit with Scrum?
The typical misunderstandings of QA with Scrum
The typical misunderstandings of QA with Scrum
QA: As the person responsible for the product quality, I do not approve the release to happen, it’s not working properly on Internet Explorer.
Product Owner: As the person responsible for maximizing the product value, I approve to go-live NOW! Also, we don’t have clients using Internet Explorer. This is no blocker at all.
QA: We have to cover Internet Explorer, it’s part of our browsers coverage. 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 audience. Otherwise, we waste our time. But for now, the go-live must happen!
Despite the fact the Product Owner and QA are in the same team and share the same objectives, the tension between them is getting higher and higher, yet, the discussion is leading nowhere. This is a typical situation between QA and the Product Owner.
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 kind of business. Therefore, QA, Tester, UX, UI, and some other roles are not part of Scrum because it would be limiting. However, the Scrum says, the Development Team has all the required skills to achieve the product goals.
Let’s have a look at the Scrum Guide to understand it better. I put in bold the critical aspects of the team.
Development Teams have the following characteristics:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
In-short, the Development Team is responsible for every required work to build a potentially releasable product. The members have no titles. In this case means QA is an activity inside the team. 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
During the retrospective, the Product Owner raised a concern “Why do we take so long to test each Product Backlog Item? I have a feeling that we are over complicating our work instead of simplifying it.”
The Development Team is responsible for the work done inside the Sprint. So testing methods and approaches are part of the Development Team’s responsibilities. Regardless if members have a title as QA or not, in the end, the accountability goes to the whole team.
The team’s Definition of Done (DoD) sets the granularity of testing. However, the Development Team often defines the details without involving the Product Owner. That’s when the problems begin because it creates a mismatch of expectations between the Product Owner and Development Team. The DoD defines what “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. So, expectations matter a lot. The Product Owner should collaborate with the Development Team to understand where it makes sense to test. For example, in an online shop, which browsers do we support? That should be clear; otherwise, misunderstandings are inevitable.
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, the Development Team presents the 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 the Development Team during the Sprint. For example, the Development Team finished one feature, then they ask the Product Owner for a validation. However, in this case, when should the Product Owner provide feedback?
I’ve seen different scenarios:
After “Done”: the task matches the DoD criteria. Then the Product Owner validates the task in a test environment and provides feedback. In this case, if the Product Owner rejects, the Development Team will need to entirely rerun some activities after changing the task, for example, tests.
As early as possible: the Development Team asks for feedback during the development phase. In this case, the Product Owner collaborates with a team member, probably on the local environment, to validate the teams understanding.
I believe in simplicity and collaboration. That’s why I think if the Product Owner provides feedback as soon as possible, the team will be more productive and efficient.
Simplicity — the art of maximizing the amount
of work not done — is essential.
Going beyond, an excellent Product Owner will encourage the Development Team to make decisions without him or her, which does not mean the Product Owner should be absent. A highly collaborative Product Owner who coaches 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’s imagine a typical scenario. The Development Team has just presented the 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?
Development Team: 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 are part of the DoD. What is missing here?
Development Team: 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 once the Development Team didn’t want to release the new features because it was failing on Kindle, even though we had no clients using this device. It was at this moment that I learned the importance of setting clear quality expectations across the entire Scrum team.
But if we need to decide on Go-live, who can do it? The Product Owner. Because the Product Owner is accountable for maximizing the product value. However, this is best served through a collaborative decision-making process versus the Product Owner unilaterally deciding without building understanding.
Some companies have a separate QA team. This scenario creates a hand-off between the Scrum Team and the QA team, which negatively impacts flow and reduces the control of the team in getting to done. In this case, both teams should define together the DoD. When it comes to deciding on Go-Life, the Product Owner is ultimately accountable for that. Still, collaboration among the teams will lead to better results.
Increasing the collaboration with the Dev Team
Two Development Team members were talking, while the Product Owner walked through the room and said: “Hey, let’s have a coffee. I have one idea to share with you.”
A great way of collaborating is by having informal talks. That’s why, as a Product Owner, whenever I have an idea, I invite some members from the Development Team to have a coffee. Generally, I like talking to someone deeper on the development and another more knowledgeable on quality assurance. I aim to get different perspectives on my idea so that we can make it better. This approach is also known as the Three Amigos.
Three amigos refers 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?
Once I started using the Three Amigos approach, we could discover better alternatives from the very beginning. This approach is useful to swarm on work in the Sprint, as well as increase the feedback loop and improve flow. The Three Amigos helps 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 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:
Set clear expectations. The entire Scrum Team defines the DoD so that the team understands where to test, what is essential, and what is not necessary.
The Scrum Team defines an efficient approach to test the tasks.
The Product Owner coaches the team problem-solving capability to allow them to think like a Product Owner and make decisions on their own.
The Product Owners collaborates with the team to decide on the Go-Live based on all facts and opinions. Ultimately the Product Owner decides with input and understanding by the whole team.
The Product Owner collaborates with the Development Team so that they can get different perspectives on ideas.