SCRUM supported by QFD

Let us start by saying that Quality Function Deployment (QFD) is not a 21st century invention. This method was already developed in Japan in 1966 to support the translation of customer requirements into specification features of products. QFD thus enables the needs and expectations of customers to be understood and translated into concrete technical specifications.

The method consists of several steps, which are presented in a matrix. In the first phase, customer requirements are identified and presented in a so-called House of Quality (HoQ). This matrix shows the relationship between the customer requirements and the technical characteristics of the product.

Even though this method was developed several decades ago, it is still invaluable today in product development and classic requirements management. It helps to ensure that products meet the needs and expectations of customers. In short: increase customer satisfaction and improve product quality.

The challenge in practice

In our specific consulting project, the challenge was the integration of a previously unused technology in combination with unclear market requirements. In this complex development environment, it became apparent early on that a shift to agile working methods would be the most promising next steps. But first we decided to use QFD to ensure that customer needs are always in focus and product development is based on clear and prioritised requirements.

Together with product management and the sales team, the diverse customer needs were listed and categorised. Subsequently, the identified needs were systematically evaluated and prioritised with the help of QFD - a crucial step for the subsequent design and prioritisation of the backlog. These results of the QFD process were seamlessly integrated into the Product Backlog.

Interactions between the individual components were visualised and the backlog prioritised according to the calculated importance for the project. The focus was also on eliminating high risks early in the project through iterative learning. At the same time, the development process was optimised through regular reviews and retrospectives, continuous feedback was obtained and it was ensured that market proximity was maintained and customer needs were always in focus.

QFD by example

We would like to illustrate the use of QFD with a simple example. For reasons of confidentiality, we understandably cannot present our real customer project. We start with an overview of the 10 steps of QFD:

1. create a list of customer requirements
2. prioritise customer requirements
3. benchmark customer requirements with competitors
4. translate customer requirements into technical product features
5. define interactions between customer requirements and product features
6. calculate technical importance for each product feature
7. determine conflicting goals
8. define technical target values for each product feature
9. perform a technical comparison of the competition (product features)
10. evaluate technical difficulty

In steps 1 to 3, functional customer requirements are collected and prioritised and translated into technical product features in step 4.

Then the interactions between customer requirements and product features are determined. This interaction matrix is at the heart of the House of Quality. It describes which technical parameters have an influence on the fulfilment of a customer requirement (step 5) and how large the respective contribution is (step 6). In this way, it can be determined how high the total contribution of a technical feature is to the overall fulfilment of customer requirements.

In this case, the ink formula with the value 72, the specific ink quantity with the value 72 and the closure with the value 73 are the most important technical parameters. In addition, the technical implementation difficulty, i.e. the risk for the realisation of the technical feature, is determined in step 10.

The success key for a structured Product Backlog

How does this help us in the creation of the Product Backlog? If we map the functional customer requirement "doesn't smear" as a User Story directly in the Product Backlog, we would develop both the ink, the tip and the manageability. In other words, almost the entire product. Unfortunately, in many mechatronic development projects it is exactly the case that a function can only be demonstrated by a multitude of physical components interacting with software. This makes prioritisation and a quick gain of knowledge difficult.

If we use QFD, we can structure and prioritise the product backlog directly according to product features or the determining components with a high contribution to customer benefit. So, for example, we would prioritise the development of the ink highly, test it with an existing tip and thus get closer to two important customer requirements such as "non-toxic" and "does not smear" at an early stage. At the same time, we would have addressed a relatively high realisation risk of 4 at an early stage.