On the IT side as well as on the client side, no one would dare say that the quality of their software is not important. Software must first and foremost be flawless, without any defects visible to the users. But is this enough? Do we make sufficient efforts when starting up a project to fully establish the expected quality criteria?

It is true that quality is difficult to measure and especially to balance in software development. First, let’s distinguish between two types of qualities:

  • External quality: It is visible to users. It involves several aspects, such as reliability, performance, usability and security.
  • Internal quality: It is not visible to users, but mainly affects the development or installation team. It involves several aspects, such as code maintainability, ease of installation, and ease of testing.

A proper mix of both types of qualities is essential. Each Product Owner wonders how to deliver value while providing a product with a consistent level of internal and external quality.

In terms of external quality, if criteria have not been defined, quality and non-functional requirements will be neglected or focus will be on features. Imagine developing an application that will have to support 100,000 concurrent users. It will be essential to establish, right from the beginning, the expected efficiency and robustness criteria. Based on these criteria, the Product Owner will have to have in his product backlog non-functional priority requirements. Plus, performance testing to ensure adequate connectivity and response time will also have to be planned early in the project. In fact, if the tests are performed late in the project, it will be more expensive to make necessary corrections.

As for internal quality, it gets complicated. Since it is not visible to users, clients are not always aware of it. It is important for the development team to communicate to the Product Owner the technical issues they are facing as well as the importance of investing in the product’s internal quality. . . Especially when the software application has a long life-time and that it will have to evolve over time. The definition of “Done” (DoD) used by Agile teams includes activities such as code reviews. However, is that enough to ensure the product’s internal quality? What would be the medium or long term impact and cost of not caring about internal quality?

For example, consider a product that will be delivered in several stages. It is very important to think about how the product will be installed, namely its “installability”. If this aspect is not well thought out and planned during the team’s sprints, the software installation will be difficult and will certainly cost several hours of inefficiency to the company.

From the beginning of the project, we need to have a business and functional vision of the software product to be developed. Similarly, it is essential to have a non-functional vision. This vision will define how the product will have to meet the external and internal quality aspects.

To choose the quality criteria that will make up the non-functional vision, the following ISO standard can be used:




To set the non-functional vision, it could be useful for the Product Owner and development team to have discussions with a software architect. Asking the following questions could help:

  • How many users will use the application simultaneously?
  • What is the estimated growth of the application?
  • How long will we have to maintain it?

Once the vision is established and clarified, it has to be visible to the entire team so that members can easily refer to it. A common understanding of the importance of non-functional aspects will help the team in the implementation of appropriate solutions.

To achieve this vision, the Product Owner will have to include non-functional priority requirements in the product backlog and prioritize them responsibly along with functional requirements.

For each of the quality aspects, there is a lot of  hidden work. It is therefore very important to understand them well, because the cost of not taking them into account is way higher to that of being proactive.

My next blog post will be about effective methods to put everything in place and prioritize quality aspects well.

Previous post

I don't have a plan yet. . . For now, I have a dream.

Next post

Pyxis /studio at Stratégies PME

François Carrière

François is an Agile coach. He seeks to understand the context of the organizations to better help them in their transformation. He coaches managers and teams in their understanding of Agility. Contact him to find out how he can contribute to the success of your Agile transition.

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.