Quality has a lot of possible definitions, and if you ask a couple of people what they understand when you say "quality", you will get almost sure a unique answer per person. Those answers will have some similarities, but in most cases there will be a lot of differences between what everybody will tell you.

This slide deck is meant as an explanation to an agile team as the Scrum Master when talking about "Quality".

When we speak about quality, you can find a couple of different definitions, depending on the level of formality a process wants to prescribe.

PMI is an organization that stands for processes and procedure and prescribes a formal way to achieve quality.

When reading a couple of guest articles (only accessible by PMI members, sorry) it becomes clear they prescribe to use a (very) formal quality process. E.g., they reference the ISO 9001:2000 standard on quality.

On the far less formal side of the spectrum (e.g. in Scrum), you have the notion of "Minimal Viable Product", which is meant as the minimum minimorum that has to be built before a product can be released.

In all cases, the intention of the quality process is to deliver a product that "fits for purpose".

In the agile approach, "Fit for Purpose" is the major objective of the product which is developed.

In order to get the purpose and how it can fit the End User requirements, you have to make the inventory of the product needs. This is directed by the Product Owner (PO) as the representative of the End Users of the final product.

The PO has to make sure the requirements are gathered the correct way so they cover at least all user expectations.

In most cases, the End User has a good idea of what (s)he wants from a product.

Because the PO and the team do an in-depth analysis of the requirements, they can sometimes come up with minor extra efforts to be spent for major added value.

Although the minimal viable product should be the first implementation shown to the public, the PO can decide to add a couple of "product exciters" so the product will be of higher value.

Once we have all requirements, they have to be prioritized to assure the team makes the most valuable product best fit for purpose.

For that reason, we need to assign priorities to each of the requirements.

The Product Owner, based on the End User requirements and the in-depth analysis together with the team, defines the priorities of the features asked for. The higest priorities will normally be assigned to the features with the highest added value.

Now, if we look at the goal of "fit for purpose", the Scrum method has a very clear approach: make sure all requirements get a specific priority and add them based on priority.

Only the highest priority is taken up first, after that one is implemented the next highest priority is taken and implemented, and so on.

As a consequence of the "fit for purpose" and the "just enough" features in a product, you have an implied balanced cost.

If we would add more features, then we will add costs to the development of our product without a clear extra monetary return.

But beware: if we would not develop one or a couple of the required features, then the product will have (a lot) less value for our Product Owner and End User.

If we only add the high priority features, then we will create the product with the highest value for the Product Owner / Customer / End User.

And of course: by learning from the parts you have already implemented, you will be able to deliver new features in a smoother/faster way because you have learned a lot about the product. This way, adding new features will become cheaper.

In the end, the product with the appropriate quality will gain a lot of market share and profitability. You don't have to be the first on the market, but it can help a lot ...

When we only deliver the real necessary features, we will have to spend less time to develop and to test the non-delivered features, hence our product will be ready for earlier introduction in the market, which is always a competitive advantage.

Once the product is sold in the market, new most valuable features can be added first.

The product can get in a kind of maintenance mode where it will most probably get a product evolution throughout its lifetime.

This evolution will be based on customer input which again implies only adding the most valuable features for which users want to pay.

The conclusions about "what is Quality in an Agile Environment" in 3 steps:

#1: make your product fit for purpose
#2: first add high value features
#3: let your product evolve

Step 1: make sure your product fits for purpose for your End User (through the Product Owner).

Step 2: By first adding the high value features, which will in most cases not be the most complex ones, you learn a lot about the product, which will make it cheaper to develop newer and more complex features.

Moreover, you will get a high value product faster.

Step 3: by putting your product earlier in the market, you will be able to let it evolve and have it aligned with your customer expectations. The more feedback you can get from your customers, the more opportunities you have to adapt the product right to their needs and wishes.

A product which is aligned with the expectations of the customer and can fulfill his or her expectations is always considered a high quality product.