So many times, I’ve heard that round about 50–70 % of all software features are rarely or never used. In the Cloud we can now even measure it. As a Product Owner, I’m in charge of the Product Backlog. If users are NOT using a feature, then I have failed as a Product Owner. Right? Wait a minute! Aren’t there feedback loops incorporated into Scrum to correct course? Yes, but maybe
there is a way to reduce waste from the get-go
In Scrum, a Product Goal is the minimal thing that a Scrum Team needs to get started and work on the Product Backlog. How do we come up with Product Backlog items? Of course, the Scrum framework isn’t prescriptive and thus doesn’t say how to do it. However, this is a puzzle piece that could make a difference in how much time a Scrum Team wastes and how creative they are.
What is Design Thinking all about?
Design Thinking is a user-centered method for creative problem solving. At the center of the method is the so-called “Double Diamond” as shown in the picture.
We first look intensively at the question which problem is worth solving. In contrast to the purely analytical approach, we first diverge in the problem space and generate a lot of data to better understand our target group and their problems and needs! Finally, we converge and formulate the problem to be solved based on the new findings. Analogously, we then diverge in the Solution Space and generate lots of ideas and prototypes for possible solutions in order to ultimately converge again based on the results of experiments. At the end of the Double Diamond we have one or more tested prototype(s). All this can happen in one day or over the course of several days or over the course of months, totally depends on the context.
How can Design Thinking help us to create better User Stories?
Let us examine the following example by Don Reinertsen:
“Customers told us that they wanted suitcases that were easy to carry and asked us to make them lightweight. We did this, but they rejected our elegant designs and bought the heavier designs of our competitors — the ones with wheels on them!”
What went wrong? The Product Owner or Developers could have written Product Backlog items like this:
As a traveler, I want alloy suitcases so that the suitcases are lighter
This is a solution driven approach, which limits the solution space and doesn’t really reflect the underlying needs of the users. Unfortunately, users often tell us solutions and not their needs.
What could the Product Backlog item be if it were driven by empathy and the underlying users’ needs?
As a traveler, I want to carry less so that I’m less exhausted
Now, the solution space is wide open which makes the life of the Scrum Team a bit harder because they need to explore options. On the other side, optionality is good because it allows you to optimize TCO (total cost of ownership) and choose the best solution for your users’ context. In our example, an alloy design probably makes the production of the suitcases much more expensive than the wheels. Even if the alloy suitcase is extremely light, the user influences the overall suitcase weight with the weight of the content. Thus, the alloy suitcase might not even work with heavy suitcase content while wheels might always work.
Lesson 1) if (potential) customers or (potential) users are talking about desired solutions, then explore the underlying needs.
What is a good way to explore the needs of the users?
For analysing needs, it is helpful to interview the users (without leading the witness though). Ask them WHY they want a solution. There is even a technique called "5 Why's", because you might not get a good answer after the first Why. Then just continue until you get to the bottom of the user's needs.
What is a good way to create options?
Actually, that is often much easier than you might think. However, the Scrum Team members need to leave their office building and go to the users. And that might be scary for some shy developers.
Let us look again at the suitcase example. If you go to the airport, then you see typical user behavior like putting suitcases on trolleys.
The inspiration is right there: “wheels underneath suitcases”. Very likely, this kind of inspiration is not available in the office of the Scrum Team.
Lesson 2) leave the building and get inspiration from the user’s context and the user’s behaviors.
It goes without saying that this article doesn’t intend to simplify Design Thinking down to the two lessons learnt above. Design Thinking is a human-centered complementary practice. On the other hand, Scrum Teams often have an existing product and “just” need to add features. For that purpose, those lessons might be helpful to get started on a journey for more creativity. However, a next step for Scrum Team members could be to learn how to interview users, create personas and synthesize research results, etc. Lucky Scrum Teams have team members on board with design skills who may bring those complementary practices to the table.