The supposition here is not to imply your approach to agile development and applying the Scrum framework is artifact centric. What is important is you leverage the use of the product backlog, sprint backlog and each product increment to check if you are doing things right.
Keeping this in mind the product backlog, sprint backlog and product increment should have the following minimal set of characteristics 3:
- Product backlog 
- The owner of the items in the backlog is known.
- The items in the product backlog have been prioritized by the product owner and have been assigned relative commercial or operational business value using story points.
- Sprint backlog 3
- Items in the sprint backlog have been drawn from the product backlog.
- The items in the sprint backlog have been prioritized by the sprint team and have been assigned an estimate to complete using story points, ideal days, or hours.
- Product increment 3
- A fully tested demo-able or production ready build (product increment) has been delivered
Though quality control should be inherent in self-directing and self-organizing agile teams the integrity of the product backlog, sprint backlog and product increment serve as an excellent barometers used to check if the team is doing the right things and doing those things right.
In conclusion, studies have shown that about 50 percent of time is spent on avoidable rework rather than on value-added work, which is basically work that's done right the first time. Once a piece of software makes it into the field, the cost of fixing an error can be 100 times as high as it would have been during the development stage.
Agile development and using the Scrum framework, with an eye on quality management, works to solve these problems by:
- An emphasis on individual, team and enterprise-wide collaboration
- effectively dealing with uncertainty by the amount and significance of learning and new knowledge gained by working through each sprint and delivering an increment of the product
- testing component dependencies earlier in the development lifecycle
- finding "missed" requirements more easily and sooner by surfacing misunderstandings in deliverables and scope
Kaizen (??, Japanese for "change for the better" or "improvement"; the common English usage is "continual improvement"). In the context of this article, kaizen refers to a workplace 'quality' strategy and is often associated with the Toyota Production System and related to various quality-control systems, including methods of W. Edwards Deming.
 The preceding items should not be interpreted as sequential in nature.
 This is not a complete list of characteristics.
About the Author
Russell Pannone is the Founder of We Be Agile and the Agile Lean Phoenix User Group, as well as the Agile-Lean Adoption Lead. With almost 30 years of system-software development and delivery experience, my focus is on working side-by-side with folks on real projects helping them deliver valuable system-software to production early and often, giving those I collaborate with the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve.