Join the 2025 limited beta student program for early access to free courses - learn more
A persistent (and wrong) myth about Scrum is that the product is released before it is actually finished, and that quality is sacrificed for speed. This is a definite misunderstanding, but if you know how Scrum works, you can easily see where the myth originates.
I want to help you understand how Agile, and particularly the Scrum framework, addresses quality and how we can claim that quality is built in. I am assuming here that you are familiar with the essential elements of Scrum, but to make sure, here is a speedy recap:
Scrum is a framework designed to manage work and deliver products efficiently in complex settings. It focuses on collaboration, adaptability, and transparency. Self-organizing teams operate in short cycles known as Sprints, typically lasting 2 to 4 weeks. At the end of each cycle, they produce potentially usable product increments. For more details, look at the Scrum Guide, which I’ll reference concepts from throughout the post.
The approach to quality in Scrum is, in essence, just like W. Edwards Deming, the famed pioneer in quality management and continuous improvement, said:
“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.”.
Avoiding backflow and rework
Quality is a crucial element in Scrum,
where the objective is to provide functional software or other products through
short iterations. However, quality covers more than just identifying and
resolving defects; it also involves creating value for customers, end-users and
other external or internal stakeholders.
Since Scrum has a lot of Lean DNA, we focus
on reducing waste and unnecessary work or rework. To do that, you need to
understand your value streams and workflows. Examining only how your product
team works is not sufficient. Value stream analysis should include the entire
product lifecycle, including product initiation and management, distribution
and operations. The DevOps approach calls this practice “shift left”: The earlier
we fix a problem, the faster, easier and less expensive it generally is to fix
it.
Always be testing, even before you build
anything; Prototyping and MVPs test deceptively simple assumptions and can save
you months of wasted work. Believe me, I have the scars to prove it.
Shared accountability and collective
ownership are important. Every problem is everybody’s problem; looking for
other departments to blame for quality issues, delays, or cost overruns belongs
in old-school management, not in being an Agile organization.
Design your product for continuous testability from
the very start. Know how you will test it and support your testing tools in the
product architecture. This is often postponed, but it is more expensive to add that support later.
Don’t use testing primarily as documentation
that your product is Done. Testing aims to find more work to do, not to avoid
more work.
AC+NFR+DoD=QA
So, Deming reminds us that we can’t just
add quality to the product, like a layer of paint after building it. Fortunately,
there are many ways to approach this, so let's go over the key elements of Scrum that
support quality management. If you remember nothing else form this post, take this with you:
The crucial elements in Scrum quality management are found in the trio of Acceptance Criteria, Non-Functional Requirements and the Definition of Done.
Acceptance Criteria (AC): Clear criteria define success for each feature and ensure it meets
quality standards. Remember, they don't always cover all the elements of a
deliverable.
Non-functional requirements (NFRs): Incorporating NFRs like performance and security ensures the
product meets broader quality standards. Remember to make them S.M.A.R.T. (Specific, Measurable, Achievable, Relevant, and Time-bound). Include
operational Service Level Agreements (SLA’s) in the product definition as an
NFR – think operations before you build. Definition of Done (DoD): Establishing a shared understanding of what it means for a task to
be fully completed ensures high-quality deliverables. The DoD is a core foundational
element in Scrum; don’t neglect it. A weak DoD is a recipe for disaster.
Calibrating the DoD is central to your delivery risk profile and your ability to
meet the business goals that are the whole point of your product delivery. Customer Involvement: Regular feedback ensures the product aligns with evolving
requirements and reduces the risk of delivering features that don’t add value.
Just remember that the interests of the end-user and your customer are not
always the same.
Incremental Delivery is a significant
aspect of Scrum. By frequently delivering small,
usable increments, the team effectively reduces the risk of defects building
up.
Actual cross-functional teams: Teams with diverse skills ensure quality is built into every stage
of development, due to the different perspectives. Sprint Review: Structured stakeholder feedback ensures the delivered increment
aligns with expectations.
Continuous Process Improvement: Regular, honest and blame-free Sprint Retrospectives and the
resulting adaptations enable the team to ensure that new, systemic quality
issues are handled. Pro tip: Put improvements and mitigations in the Product Backlog
to enable tough prioritization decisions.
Engineering standards and industry
practices: Scrum teams should continuously focus on
technical excellence and craftsmanship. Make sure they have the time to do
this.
Active dependency management: Never assume that other teams or external suppliers will
prioritize your success over their own, even if you are the best of friends.
Agile testing
In Scrum, we don’t separate business goals
from product goals that much since they ought to be synchronized, including
technical goals. So, when we test, we see these elements as part of the same requirements.
We don’t just test for defects (bugs); we also test for missing the intended
outcomes of the product, and testing is integrated into every stage of
development, ensuring that problems are detected early. Agile testing should be
conducted following a few fundamental principles:
“Everybody tests.” Quality is not just the job of the QA team—it is the shared responsibility of the entire team, including developers, product owners, and even customers.
Test and release early and often. Short feedback loops help teams identify and resolve issues quickly before they become costly.
Focus on frequent value delivery, delivering and testing in small, manageable chunks. This means testing fully integrated products whenever possible.
Don’t waste resources – only do the necessary tests, but always do all the necessary tests.
Since the development method is adaptive, you might be improving the way you test continuously.
Some Agile settings prioritize testing based on business value and risk. In this approach, high-risk areas are tested more rigorously to minimize potential failures, but this depends on your risk appetite and who defines what is classified high-risk. If stakeholders are not aware of consequences this principle, they might become complacent and be surprised when bugs end up in the hands of the customers. Remember, this means exactly that you are not testing everythingequally. UI might be prioritized lower than transactions in a banking app, for instance. That might seem as common sense, but if the branding of a customer's app is wrong, you prioritization might be challenged.
Automate where possible, it improves efficiency by enabling continuous integration (CI) and continuous deployment (CD). But do apply common sense; automation also enables the making of many big mistakes very fast.
Use the Agile Testing Matrix for inspiration when designing your test strategy. It can point out gaps where you might not be covering QA needs.
Planning is a common activity in Scrum. If you are used to working with traditional project teams, replanning every two weeks can seem counterintuitive or even indicate that the team doesn’t know what it is doing. However, this is how we solve a complex challenge that cannot be pre-understood in detail, which is the typical mission of a Scrum Team.
Our structured approach incorporates solving the problem one chunk at a time, re-analyzing our new knowledge and deciding the steps towards the next milestone.
To ensure that the iterative, adaptive approach is valid, we put a lot of effort into recalibrating and gathering knowledge about the product and the process, and we must focus on creating the best possible plan with the available knowledge at any given time.
In essence, we embrace PDCA (the Shewhart cycle):
Plan - Identify the problem, set objectives, and develop a strategy for improvement.
Do - Implement
the plan on a small scale to test its effectiveness.
Check - Measure
and analyze results to determine if the change worked as expected.
Act -
Standardize the successful changes or adjust and refine the plan before
repeating the cycle.
Sanity-check the plan: Use
the Confidence Vote technique to uncover hidden insights among team members and
their stakeholders. Good plans do not always lead to good outcomes, but bad
plans rarely do. Be prepared to ditch wishful thinking and yes-hattery. Accept
the bad news and fix the problem.
This is enabled by confidence voting, where all participants give a vote of one to five that indicates their confidence in the feasibility of the plan. If the average vote is below 3, a new discussion will help uncover new knowledge and a re-vote. It exists in several versions and is often used in Scaled Agile settings.
Enter a Planning Pact across the organizational
hierarchy. This concept is not an official part of Scrum, but it
is highly recommended:
Teams agree to do everything in their power to meet the agreed objectives.
Management agrees to do everything in its power to minimize outside disturbances.
If the plan becomes unfeasible, teams agree to escalate immediately so that corrective action can be taken.
The pact is typically agreed after a review and correction of a plan. This reflects Agile principles, where teams are encouraged to communicate issues quickly to facilitate timely corrective actions.
Don’t kick the can down the road
While it can sometimes seem attractive to take shortcuts in product development, doing so might result in technical debt, which in turn will make it slower and more challenging to improve the product later. This is a tricky problem with no easy answers.
When is it appropriate to skip quality or diligence to meet a business requirement? The development team is responsible for pointing this out, but it should be an informed and documented business decision when to incur technical and process debt and face future consequences. Don’t kill the messenger when you get annoying pushback from your Scrum Team. You will probably stop getting messages.
You’ll learn to engage with Scrum teams, improve collaboration, and build agility in your organization. The course covers Scrum fundamentals from a leadership perspective, focusing on your role in supporting product development, managing expectations, and aligning business goals with team outcomes.
Get ready to transform how you lead and collaborate. Scrum for Managers and Stakeholders is your tool to succeed in the fast-paced Agile world!
Christian is an Agile practitioner, seasoned project manager, accredited Scrum & DevOps trainer and leadership consultant. He is now bringing his expertise and unique view of Agile, modern leadership and related disciplines such as Scrum and DevOps to the students at the Corporate Revolutionary Academy, which he has co-founded.
