Scrum is an agile framework for solving complex problems and exposing progress all along the way. More specifically, scrum is an empirical process control framework. Each piece of the framework does at least one of the following:
- Ensures unfettered transparency, to enable…
- Frequent inspection of progress and quality, so that…
- Immediate adaptation can be made in response to reality
In complex systems, it’s easy to get things wrong. Getting things right takes discipline, continuous inspection and adaptation. Defects, or bugs, are significantly lower with scrum. If practiced properly, the concept of a bug shouldn’t exist.
Scrum ensures quality is embedded throughout your solution or product development cycle through scrum’s three roles, three artifacts and five events.
Definition of “Done”: focus on shippability
Before a scrum team does any development, they agree specifically on what quality means for the functionality they will create. Foundational for providing a quality product is the team’s definition of “done,” or the team’s quality standard of what it means for their developed functionality to be shippable at the end of a sprint. Scrum teams work on the next highest priority channel of valuable functionality at a time until it is complete and shippable, then they start on the next highest priority item until it is complete and shippable, so on and so forth. Each new piece of functionality created is incremental to what was implemented previously. The scrum team knows at any given time that what they’ve developed thus far works and is what the customer wants, and wants most.
Traditionally, developers would say, “It works on my computer.” It was a commonly used definition of done, but it’s a horrible definition. And, it won’t work in today’s rapidly changing technical environments and markets.
A scrum team’s definition of done will specifically, and at the very least address the following aspects of the product or solution’s development:
- Environment: In what development environment can we be confident our newly implemented functionality has been sufficiently tested and integrated at scale, and could ship to the customer, if there was enough customer value to do so?
- Testing: What types of testing are required to ensure there are no defects and the newly created functionality meets the customer’s needs? Keep in mind, testing must be automated, not manual. Without automation, you cannot be confident in your testing coverage of the entire product or solution on a recurring cycle. It will also be difficult to be agile in adapting quickly to market conditions which affect your customer’s competitive advantage.
- Documentation: What types of documentation are useful and necessary to ensure the newly created functionality can be deployed and supported effectively and efficiently? Scrum teams do value documentation—it just needs to be useful and barely sufficient. Could another team pick up your team’s work without missing a beat? Can others support the customer without your direct assistance? Unclear or bloated documentation could negatively impact your customer.
Scrum teams build done, working, shippable functionality every sprint by adhering to their definition of done.
Acceptance criteria: focus on desired outcomes
Acceptance criteria is key for developing a quality product by describing the outcomes and expectations for resolving a customer or end-user’s problem. Before scrum teams begin implementing a user story, they arrive at a shared understanding of what success looks like through clear acceptance criteria. Clear statements in the form of “When I do X, Y happens” are useful for eliminating ambiguity and vetting ideas.
Acceptance criteria also enables alignment between product development and test case creation—in fact the acceptance criteria outlines the test case script for you. Agile teams build, test, inspect and adapt repeatedly until they meet the acceptance criteria and the definition of “done.”
Scrum teams are also clear on scope when they have clear acceptance criteria. This avoids a product owner reviewing a completed user story’s functionality and saying, “Actually, I think I’d like it to do this,” and requiring additional scope. Acceptance criteria is a clear delineator of where one user story ends and a newly discovered user story begins. New user stories go on the product backlog for prioritization in a future sprint.
Working with the product owner to put new ideas on the product backlog is an effective approach for iteratively removing defects, yet allowing the team to stay focused on the immediate sprint and release goals. At the very least, daily scrums can be helpful for providing transparency about work deviating from the acceptance criteria.
Scrum roles focus on quality
Each of the scrum roles—product owner, development team and scrum master—are key to product quality.
Product owners focus on quality assurance
Product owners represent the customer and stakeholders by setting quality expectations. They are the “voice of the customer” for the scrum team and continually ask, “Will the new feature meet the needs of my customer?” Their continued access, clarification and guidance to the development team provides the proper perspective. Daily, the product owner inspects and approves or rejects each completed user story, ensuring a quality product increment. While the development team ensures quality control (see below), the product owner ensures quality assurance.
A product owner makes the decision about when completed functionality is ready to release to users, in collaboration with the customer, stakeholders and the development team. The customer’s involvement every sprint review gives the product owner confidence what gets released is going to satisfy the customer. The scrum team’s definition of done and each user story’s acceptance criteria give a product owner confidence that what will be released is technically solid. Once released, customer feedback simply becomes a new product backlog item to be prioritized.
Every user story is chosen each sprint to align with a sprint goal (demonstrating tangible and valuable functionality that is shippable), which aligns with a release goal (enabling the customer with new functionality they didn’t have before), which aligns with the product vision and product roadmap, which provide the outer boundary of scope and purpose.
Product owners own the product backlog and its prioritization. They expose the product backlog to all stakeholders creating the opportunity for early feedback on the contents and ordering thereof. This feedback and ownership ensure that the team is always working on the next highest value and next highest risk features. Careful backlog refinement prevents the team from building the wrong product features. Reviewing these upcoming backlog priorities with stakeholders during sprint reviews is also a key activity for product alignment to customer needs.
Development teams focus on quality control
While the product owner is responsible for optimizing value delivered by the development team, the development team is responsible for the technical quality of what is delivered.
Effective development teams work together on a single user story at a time (commonly known as “swarming”) to limit their work in progress (WIP). Limiting WIP optimizes flow of work, which means scrum teams get to done more frequently than teams that start many items at once. With high WIP, the result is frequent context switching (also known as “thrashing”), lots of work started but not finished at the end of the development cycle, and working non-collaboratively in silos leading to single points of failure in knowledge and skill.
By swarming, each user story is elaborated, designed, developed, tested, integrated, documented and approved—fully baked. Each user story is completed faster. Volume of delivered value increases. Testing is not put off until later, and is done in small, manageable chunks to minimize complexity and error. The development team members provide each other with minute by minute quality feedback as they swarm on tasks throughout the day.
Although not part of scrum, development teams use other good technical practices to build in quality, frontloading their risk all along the way. Extreme programming (XP) practices are most commonly used in software development, and comparable practices specific to other types of product development should be used as well. XP practices commonly used include:
- Test-driven development (TDD)
- Continuous integration (CI)
- Coding standards
- Shared code ownership
- Refactoring
- Simple design
Other design thinking and lean product development approaches, such as behavioral driven development (BDD), help development teams reduce wasteful and unnecessarily complex architecture and implementations.
Development teams who carefully own the sprint backlog ensure quality. The method used to build the sprint backlog during sprint planning enables the creation of a quality product. Through the sprint planning agenda of first focusing on what the sprint goal should be and identifying the stories needed to accomplish the goal helps the team to focus on customer needs. Then, secondly, planning how the team will accomplish the sprint goal helps everyone on the team align on the quality expectations in advance. Many teams even use their definition of “done” as explicit tasks needed for each story to ensure quality. Calling for consensus at the end of sprint planning enables the team to understand if they’ve adequately pulled from the product backlog with enough time to build a quality product increment during the sprint. The time box of the sprint itself creates a development rhythm, encourages focus, and provides a healthy balance of tension to build the right thing for the customer with high quality standards.
Scrum masters enable quality outcomes
Scrum masters also play a key role in ensuring product quality, but from a more influential stance, as they focus on improving the team’s effectiveness. Scrum masters continually remind the team of their definition of done, particularly during sprint planning, product backlog refinement, sprint reviews, retrospectives and even product owner sign-offs. They also coach the product owner to manage their backlog focusing on delivery of value early and often. They remind the team to “welcome change, even late in development, to harness change for the customer’s competitive advantage” as well as the other 11 agile principles. Sprint retrospectives are key opportunities for scrum masters to help the team reflect on the practices they use to provide a quality product.
Scrum masters facilitate using timeboxes and provide clear guidance on the purpose of events, making sure all participants understand the desired outcome and ask questions to assure the desired outcomes are reached. They also coach the entire project team (scrum team and stakeholders) on using and providing transparency to enable quick feedback cycles. Without effective individuals and interactions, the development processes used by the team won’t continuously improve. Improvements, resulting from facilitated retrospectives, lead to more effective teams that deliver higher quality, earlier and more often.
Stakeholders provide quality feedback
At the end of each sprint, scrum teams ensure the opportunity is available for any and all stakeholders to inspect the product increment during sprint reviews. Feedback from stakeholders, which should be given early and consistently throughout product development, is key for ensuring a quality product. Their perspective on priority and value for a scrum team is extremely helpful in delivering a quality product.
Stakeholder feedback on the product increment during the sprint review can also guide the direction of the next sprint. Feedback is based on what has been done and what reality has shown. Even though the product increment may have reached the definition of done and is working, stakeholder feedback informs what should be created or explored next.
Once released, even more quality feedback comes from actual users or customers.
In scrum, quality is inspected minute by minute, daily, at the end of each sprint, and after every release. The three scrum roles (product owner, development team, scrum master) and stakeholders all ensure quality. The three scrum artifacts (product backlog, sprint backlog, product increment) and the five scrum events (sprint, sprint planning, daily scrum, sprint review, sprint retrospective) each enable empirical process control through unfettered transparency, frequent inspection, and immediate adaptation. If disciplined in using the scrum framework, the days of bugs, defects and “breaking production” should be gone. Truly, “working software is the primary measure of progress.”
Decrease defects and improve quality with our help
Looking for agile talent to improve your product quality? We’ve trained over 10,000 agile professionals. Ask us how we can help you in your agile journey.
