What Is Quality?

Agile teams build high-quality products. Agile team members write high-quality code. Agile teams produce functionality quickly by not sacrificing quality.

Each of these is something I’ve said before. And if you haven’t said these exact things, you’ve likely said something similar.

Quality gets mentioned a lot in discussions about agile. And so, perhaps it’s worth clarifying my definition of quality. Of course, others have thought about quality more deeply than I’m capable of. And so, I won’t be providing a new definition of quality here. But I will explain how I think of quality.

One of the leading advocates for quality was Philip Crosby. In the 1970s he proclaimed that “quality is free” because doing something right the first time at a high level of quality was cheaper than fixing it later. Crosby defined quality as “conformance to requirements.”

I never really bought into Crosby “conformance with requirements” approach (even before agile came around) because there was never a way to be confident requirements were accurate. Saying something like old Microsoft Bob was high quality because it complied with some ill-conceived requirements document never felt right to me.

Similarly, quality isn’t just being bug-free though, as that’s the same problem.

Another approach to defining quality comes from Joseph Juran. He was one of a number of management theorists who worked in Japan in the 1950s. Juran defined quality as “fitness for use”:

"An essential requirement of these products is that they meet the needs of those members of society who will actually use them. This concept of fitness for use is universal. It applies to all goods and services, without exception. The popular term for fitness for use is Quality, and our basic definition becomes: quality means fitness for use."

This definition of quality really resonates with me. Quality is “fitness for use.” A high-quality product does what its customers want in such a way that they actually use the product. Something that conforms to ill-conceived requirements (such as Microsoft Bob) is not high quality. Something that is buggy isn’t high quality because it isn’t fit for use.

What do you think? Is quality best thought of as “conformance to requirements?” Or “fitness for use?” Or perhaps something else entirely?

About the author
Mike Cohn
Author: Mike CohnWebsite: http://www.mountaingoatsoftware.com/
Agile Software Practitioner, Coach, Author and Owner at Mountain Goat Software
Mike Cohn is one of the contributors to the invention of the Scrum framework. He is one of the founders of the Scrum Alliance and owner of Mountain Goat Software, a company that provides training on Scrum and Agile software development techniques.He began his career in the early 1980s as a Programmer in APL and BASIC before moving on to C++ and Java and running development groups. Cohn ran his first Scrum project in 1995 and has been a vocal proponent of Scrum ever since. Cohn is the author of Agile Estimating and Planning, User Stories Applied for Agile Software Development and Succeeding with Agile: Software Development using Scrum, as well as books on Java and C++ programming[4] and articles for Better Software, IEEE Computer, Software Test and Quality Engineering, Agile Times, Cutter IT Journal, and the C++ Users' Journal. He is also the editor of the Addison-Wesley Mike Cohn Signature Series of books. In 2012, Cohn was named #1 in The Top 20 Most Influential Agile People.

Past Events

Our Services

Contact Us

Bosnia Agile
Milana Preloga 12, Sarajevo 71000
Bosna i Hercegovina

This email address is being protected from spambots. You need JavaScript enabled to view it.