What Quality Means in Agile
- Define quality using PMI's multiple accepted definitions and recognize which applies to a scenario
- Name the eight attributes and the factors that shape a product's actual quality
- Explain why agile principles build quality in continuously instead of inspecting for it at the end
Quality is a measure of whether the product meets customer needs — both intrinsic (how well it's built) and extrinsic (how much value it delivers). W. R. Spriegel's classic definition frames it as the sum of a number of related characteristics — shape, dimension, composition, strength, workmanship, adjustment, finish, and colour — a reminder that "quality" is never one single property, it's a bundle of them. PMI accepts several overlapping definitions: degree of excellence, conformance to requirements, fitness for use, fitness for purpose, freedom from defects, and delighting customers. None of these is "the" definition — a question may lean on any of them, so recognize the underlying idea rather than memorizing one phrasing.
Eight attributes of product quality are commonly tested: Performance (does it do what it's supposed to), Features (what it offers beyond the baseline), Reliability (does it keep working consistently), Conformance (does it meet the stated spec), Durability (how long it lasts under use), Serviceability (how easily it can be maintained or repaired), Aesthetics (how it looks and feels), and Perceived Quality (the customer's subjective impression, which doesn't always match the other seven objective attributes).
Several factors shape how much quality a product actually ends up with: Market expectations, Technology available, Cost constraints, Time to market pressure, Materials used, Resources available, Company policies, and Management support. A product can be well-designed and still ship with lower quality than intended if, say, management support for proper testing time was never there.
Quality is built into every aspect of agile, not treated as a separate phase. The goal is high-quality products delivered with speed, simple and maintainable code, and continuous improvement driving user satisfaction — quality isn't a checkpoint at the end, it's continuous throughout.
Several of the Agile Manifesto's twelve principles are explicitly about quality: principle 1 (satisfy the customer through early and continuous delivery of valuable software), principle 3 (deliver working software frequently), principle 7 (working software is the primary measure of progress), principle 9 (continuous attention to technical excellence and good design enhances agility), and principle 12 (at regular intervals the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly). Compared to a traditional approach, agile's mindset toward quality is collaborative and built-in rather than competitive and inspected-for; feedback and incorporation happen continuously with every iteration instead of once at the end; testing is an integral, daily activity rather than something with a large time lag after coding; defects are easier to isolate because work is handled in small pieces; risk is lower because testing happens constantly rather than being compressed at the end under schedule pressure; and quality is actively assured through pair programming, code reviews, refactoring, and continuous testing rather than being the first thing sacrificed when deadlines get tight.
Study focus: when a question lists several "attributes of quality" and one option is clearly about the customer's subjective impression rather than a measurable property, that's Perceived Quality — it's a real, named attribute, not a distractor, even though it's the only one of the eight that isn't objectively measurable.
Key terms in this chapter
Quality · Conformance to requirements · Fitness for use · Performance · Reliability · Serviceability · Perceived quality