Direkt zum Hauptbereich

How architectural quality fertilizes customer satisfaction

How architectural quality fertilizes customer satisfaction 

Architectional quality as crucial part for sustainable customer satisfaction
Architectional quality as crucial part for sustainable customer satisfaction

Does your team have a deep understanding on how to leverage quality requirements? Does your product backlog consist of infrastructure and quality requirements? Is your team aware of what drives customer satisfaction? 


If we did catch you with one of these questions, you should read our article in which we cross the bridge between technology and organizational development.  


We hope that the article itself helps to rethink your status quo and helps you personally on your learning journey. Let’s grow – your Agile Gardeners, Dominik & Michael 



Part of our mission as Agile Gardeners is crossing the bridge between technology and organizational development to nutrisionize sustainable systems. Typically, we encounter three different scenarios when working in teams with digital products: 

  • Scenario 1: The teams underestimate the leverage of quality requirements.  

  • Scenario 2: The team’s backlog lacks room for infrastructure and system quality requirements although the team knows that they are poorly implemented. 

  • Scenario 3: The team is not aware of what drives customer satisfaction. 

In this blog post, we address all three statements, evaluate the consequences, and propose approaches on how to deal with them. 

Scenario 1: The teams underestimate the leverage of quality requirements


Before we tackle this statement, we first want to understand: What is quality? 

Gerald M. Weinberg coined the statement  “Quality is value to some person.”  

Consequently, we have to collaborate with our stakeholders closely to understand what quality means to them.  


Product backlogs should therefore both include functional and non-functional requirements. In that context, we recommend enriching functional requirements with acceptance criteria with respect to quality. Value creation blossoms if both parts are well-balanced. 


Quality requirements only indicate but don’t guarantee the system’s ability to provide value and generate customer satisfaction. The ISO 25010 describes a quality model that collects some necessary system attributes. 

Software Product Quality: Taken from ISO 25010 Quality Model 

As agile Gardeners, we train teams, product owners, and all stakeholders in that context. As an important step, we create transparency of the quality requirements and foster communication about these properties with all stakeholders while empowering the development team. In the end, understanding technical debt as a huge source of opportunity costs is the key to growing the whole team in taking responsibility for quality requirements.  

Experienced Behaviour of quality costs
Experienced behaviour: Changing Quality comes with exponential cost over maturity

Scenario 2: The team’s backlog lacks room for infrastructure and the system’s quality requirements

We often encounter product teams that have a strong focus on functional roadmaps with nearly no focus on infrastructure and architectural topics. This behavior often becomes visible in reflecting the number(absence?) of technical tickets in the team backlog 

As Agile coaches, we see the potential conflict between building lightweight MVPs and building our features based on fundamental architectural quality requirements. As Agile Gardeners, we resolve this conflict by emphasizing and visualizing this conflict to the team and all stakeholders. Continuous backlog refinement of functional and quality requirements is crucial.  

This potential conflict is already deconstructed by agile principles written down in the agile manifesto itself: 

  • “Our highest priority is to satisfy the customer through early and continuous delivery 
  • of valuable software.” this tells us to foster MVP approaches. 
  • Continuous attention to technical excellence and good design enhances agility. -tells us not to forget technical improvements on the go. 
  • Welcome changing requirements, even late in development.- Tells us that the whole team should also be open to basic technical improvements on the go.  

Therefore, we emphasize that agility needs continuous room for changing and reflecting software architectures. 


Modern software architecture approaches point out to start with quality requirements as they form fundamental, hardly revertible decisions about architectural design. This is why the arc42 template suggests describing quality goals at the start of any software architecture. Exploring them at an early stage and discovering possible trade-offs between competing quality requirements is key for a successful system design. Quality scenarios help to derive quality drivers by describing various usage, change, and failure scenarios.  


A quality tree breaks down the key quality drivers and assigns metrics for measuring them – because what you measure is what you get, and when you don’t measure anything, you won’t get to anything. Comparing these metrics against their target values will help your team prioritize the backlog and ensure that you always match up with your quality requirements.

Quality Tree Arc 42 https://docs.arc42.org/tips/10-2/

As agile Gardeners, we love to balance the named potential conflict. We moderate workshops to create quality trees and work out quality goals.  

We train development teams and Product Owners to work out the properties regularly on their own. We welcome to see building software architecture as an incremental approach to explore the best possible solution. On the journey, teams learn more about the required key properties. Therefore, we encourage the team to welcome the incremental development of the architecture. Product Owners need to master balancing technical topics besides functional improvements. 

In that context, the key is to manage expectations and consensus with all stakeholders. Building transparency as a first step and then integrating the topic in the Scrum learning loop of the team is the foundation of success.

Scenario 3: The team is not aware of what drives customer satisfaction. 

Go to your team and simply ask “What does the customer think about your product”. With a good chance, you will get some inconsistent or meaningless answer because too many teams don’t work customer-centrically. This may be an issue due to the misleading focus on product delivery when applying Scrum because it does not say anything about how to integrate product discovery and aim for a high user experience.  
An evaluation of the customer satisfaction drivers combined with a quality tree can assist with product backlog prioritization of features and quality requirements. Here you have an example of the Kano satisfaction model: 

Model: Taken from Val Yonchev 2018 

KANO Step 1: Question Survey template

KANO Question Survey 

I like it 

I expect it/ Must-be 

I am neutral 

I can tolerate it 

I dislike it 


How would you feel if the product had ...? 

if the app has 2-factor authentication, how do you feel? 






How would you feel if there was more of ...? 








How would you feel if the product did not have ...? 

e.g., if the app does not have 2-factor authorization, how do you feel? 






How would you feel if there was less of ...? 







Own image; KANO survey template 


KANO Step 2: KANO Evaluation & KANO evaluation example "2-Factor Authorization"

In terms of KANO, functionality here refers to the degree of fulfillment of customer requirements (be it functional or non-functional (aka quality) requirements). 

In Xu, Q et al (2009), Must-be/Must-be and Tolerate/Tolerate are marked as “Indifferent”, although it seems contradictory to us. We, therefore, marked it as “Questionable”.  

The Q-Categorization (Questionable) controls for an incorrect understanding or a reckless answering process. 

KANO Step 3: Categorization of requirements into KANO satisfaction drivers

Own table: KANO scores for continuous categorization
Own table: KANO scores for continuous categorization 

By calculating the average for each functional and dysfunctional question form, you get the y (functional) and x (dysfunctional) coordinates for localizing the feature in the matrix. This continuous analysis (based on average) is superior to the discrete analysis (based on mode) because less information is lost in the visualization.

Own diagram: Example for KANO continuous requirement categorization
Own diagram: Example for KANO continuous requirement categorization 


In the discrete analysis, you assign the feature category to the one with the highest consensus (mode) among the responses1 – this approach is problematic if you have high variance in your answers.

Own diagram: Example for KANO discrete requirement categorization
Own diagram: Example for KANO discrete requirement categorization 

 As agile Gardeners, we love to grow customer orientation in Teams. Besides personal coaching and working out things like why the team works together, there are multiple methods that foster progress. We use retrospectives to deep dive into topics like Value Proposition Canvas, Business Model Canvas, Vision Statements, Personas,  

Further, we encourage building formats that integrate real customer feedback like demos, interviews, or data reports based on the interaction of the client with the product. A deep dive into the KANO model can both leverage product Owners to the next level for prioritization and also mature a whole development team, when it understands, that everyone is needed to work out relevant requirements.  



Imagine living in a team that solved all these three challenges. You would work in a context where teams value the high importance of quality requirements and therefore have a clear understanding of them communicated properly to all stakeholders. The same teams would give infrastructure topics and quality requirements the deserved space in backlogs. Most crucial: These teams won’t get lost in working out quality standards only, but learn to validate what drives customer satisfaction and therefore overall prioritize the customers’ good. 


What are your impulses to the topic? 

Which of the named methods are part of your methods? 

What inspired you and contributed to your growth? 

We are happy if you comment under the article or contact us. 


We learned that it’s possible to grow these teams. In our experience these teams blossom, their products become extraordinarily successful, and mostly the whole organization gets inspired by them. We hope that you enjoyed reading the article and that the impulses help your team on that journey. All the best and let’s grow,  

Agile Gardeners Dominik & Michael 



Agile Manifesto. https://agilemanifesto.org/. Accessed 18.11.2023 

arc42 Documentation. Home | arc42 Documentation. Accessed 18.11.2023. 

ISO 25010 Quality Model. ISO 25010 (iso25000.com). Accessed 18.11.2023. 

Amy G. Application of the Kano Model in Understanding Consumer Preferences and Product Attributes in the Vacation Ownership Industry. JOJ scin. 2021; 2(4): 555592. DOI: 10.19080/JOJS.2021.01.555592 

DuMouchel, “Thoughts on graphical and continuous analysis.” Center for Quality of Management Journal 2.2 (1993) 

Fong, “Using the self-stated importance questionnaire to interpret Kano questionnaire results.”, The Center for Quality Management Journal 5.3 (1996) 

N. Kano, N. Seraku, F. Takahashi, S. Tsuji: Attractive Quality and Must-be Quality. In: Journal of the Japanese Society for Quality Control. 14(2) 1984, S. 147–156. 

Val Yonchev. Kano Model: Easily visualize and explain the impact and priority of different features.https://openpracticelibrary.com/practice/kano-model/ (2018). Accessed 18.11.2023. 

Xu, Q., Jiao, R. J., Yang, X., Helander, M., Khalid, H. M., & Opperud, A. (2009). An analytical Kano model for customer need analysis. Design studies, 30(1), 87–110. 





Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.