How Does Quality Assurance Fit With Scrum?
QA:?As responsible for the product quality, I do not approve the release. It’s not?working 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 the?same 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 some?other 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 often?define 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 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.?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?
领英推荐
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 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 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 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 team’s control in getting to done.?In this case,?both teams should define the DoD together. When deciding on Go-Live, the?Product 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 of?collaborating 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 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? —?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 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 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:
?? A.I. Engineer ?? AND ?? Blockchain Developer ??
2 年Appreciate bringing this topic up, David. The constant tension between product and QA is obvious. But it can be resolved with empathy from both sides and common ground made on business objectives. Every so often, the tension occurs because of the process. People are working in the silos, who are supposed to have common business objectives. People lose sight of the big picture because of the silos working environment. More writing pieces like this article written will definitely help elevate the product development and product management standard.
Expert in Software Quality Engineering · Founder of QA Roots · International Speaker · Coach · Trainer
2 年David Pereira absolutely great article, I agree with you and I think that the synergy between Product and QA helps incredibly deliver great products and services, so I always foster a strong collaboration and continue communication and alignment between the two roles/teams, and the 3 Amigos is a good way to do that together with - for instance - a proper usage of BDD methodologies, for instance via Cucumber (and clearly avoiding the typical pitfalls in using it). Also worth to mention is that (and I think this one key aspect of a great company mindset) delivering quality belongs to the entire team, no matter the role, and not just to the QA Team, which should be instead perceived as that "extra safety net" to grant quality, anyway - metaphorically talking - a tightrope walker would not do it just because there is net in case of falling, but because of being confident. Thanks for your words and it was great to work together, I equally learnt a lot from you and cannot wait to work together again :)
Qualisoof, senior (quality) consultant, speaker and trainer @OrangeCrest
2 年what I am completely missing in this post is the value of doing a product risk assessment: the team and PO should be aware, upfront, about worries that they have that, can go wrong. Discussion of its works on a kindle would have been a non-discussion because it would be put out of scope. If you really want to focus on quality as soon as possible, use the risk analysis. And of course, it is the PO that makes the final call, the QA (although he/she never assures quality ;-) ) just gives advice together with possible actions that can be taken if the risks that are still open occur. That is the way a QA can really help the team and the PO: he/she understands the context! Besides, you are talking about validation, but where is verification? Maybe you should have a look at the Agile testing quadrants of Lisa Crispin and Janet Gregory to define a quality approach in your scrum team: https://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
Connecting distant complements.
2 年this reminds me so much of the old days in CSOB. ?? I imagine the things must have improved a lot since then… Libor Pavlík Markéta Matou?ová Jan Jelínek Roman Masek
Test Consultant at Fujitsu
2 年Excellent article. #RapidElicitationAndAnalysis #BusinessAnalystTester #AcceptanceCriteria #Speed #Quality #Value. ?? #IncreasedClarityAndSharedInformation #ReturnOnInvestment #EngineerInQualityFromTheStart