The problems of integrating a Design Thinking approach with a Scrum operational framework

After introducing you to the Design Thinking approach and its usefulness for product management, we share with you some problems frequently encountered by our clients.





Problem 1 - Having a fully structured product backlog based on the screens from the prototypes


The learning generated through prototypes can lead to the construction of a Product Backlog that is completely oriented towards "action on the graphical interface", to the detriment of functionality. We have observed that the writing of User Stories can be broken down into a User Story describing the access to a screen or information, and a second User Story describing the expected screen or information:

US 1: As Richard I want to click on the "My Orders" button to access the list of my orders
US 2: As Richard I want to see a list of my orders sorted by date of creation in order to know the delivery status of the last order I placed.

By confronting these two User Stories with the INVEST model they should follow, we see the following:

  • I - Independent - The two US are dependent on each other. If one is not realized, the other is not usable.

  • N - Negotiable - The first US is too simple and small - There is no possibility to negotiate it.

  • V - Valuable - What is the value of clicking a button to access a list of orders? No value. The first US is way too small.

  • E - Estimable - Yes of course.

  • S - Sufficiently small - Yes, but they are even too small.

  • T - Testable - Yes they both are, although testing the display of a screen or a feature when a button is clicked is not the most interesting and relevant test to perform.

This type of User Story breakdown, oriented towards the graphical interface, imposes a too high workload on the development teams and their product owners. The former have to set up tests to validate topics that do not provide value. The latter spend too much time writing small User Stories, often to the detriment of discussions with users or market analysis.


Problem 2 - Time to market of the product is slowed


The vast majority of the five phases of the Design Thinking approach are completed before the implementation is launched. The Scrum framework has allowed us to drastically reduce the start date of the implementation of the features compared to traditional project management approaches.

We have seen several times with different clients that the Design Thinking approach was fully realized before any development was launched. The deliverable for the development teams was a complete and validated prototype of what was to be done. This means that a detailed specification phase has to be completed before the implementation can be launched.

This causes a delay in the first sprint, a delay in feedback on the increments made and therefore a delay in the market launch.


Problem 3 - We don't take advantage of increasing the functional knowledge of the development team


We have found that many of our clients have restricted their Design Thinking approaches to experts. If the development team cannot participate in the different phases of the approach, it cuts itself off from the knowledge of the users' context and the real problems they are trying to solve. As a result, the team will only be able to contribute very little innovation. We must not forget that a team cannot be efficient if it does not know the functional subject and the real problems it must solve. It will be content to implement solutions imagined by others.


Problem 4 - The validated prototype is considered a validation of the hypotheses


The Design Thinking approach limits the risks of targeting the wrong solution to answer users' problems. However, just because a prototype is validated by users does not mean that the solution is satisfactory for them. Here are two cases that we have encountered with our clients:

  • the users the client relied on to carry out the Design Thinking