Anyone who has been within earshot of a toddler has encountered this dreaded situation: a never-ending parade of the child asking you “why?” over and over again until they (and potentially you) are blue in the face. …and on and on it goes until eventually, the authority figure bemoans, “because I said so!”

Although this anecdote might seem humorous to onlookers, this problem solving isn’t exactly what we could call successful. But what happens when you’re dealing with stakeholders, SMEs, and major clients? Our strategy must be precise, direct, and help us to get the answers that we need to move forward in our development and re-focus our efforts.

One of the most important skills that you can have as an effective Scrum Master or Project Manager is the ability to ask the right questions. By being able to ask questions effectively, you not only get the right answers to take back to your team, but you may also save your precious time—and your client’s, as well. A lot of the time, questions can be directed toward the product owner or stakeholder to better understand the needs of the team and to move towards the next project milestone.

With that in mind, I’d like to share my favorite tool for asking the right questions at the right time: the 5 Whys.

Why the "5 Whys" framework?

Unlike our previous situation, we want to ensure that the questions we ask create a deeper understanding of a product, the rationale behind a request, and a stronger means to serve the end goal of getting a shippable product out within a short period of time.

Developed by the Toyota Corporation in the 1930s, the 5 Whys root cause analysis has been a popular and well-documented tool for Scrum teams and project managers of all industries. Much like peeling an onion, we use strategic questions to strip away the layers and get to the heart of an issue, understand cause and effect, and understand relationships within product development.

As the name suggests, we ask why (no less than) five times to work towards a suitable solution for our client’s problem. Each question probes into different perspectives, reasoning, and relationships that helps us to gain a better understanding of their needs for better project and team alignment.

Putting the 5 whys into action

Problem Scenario:

A stakeholder requests changes to the UI (User Interface) of their responsive website. The client requests that the login button is moved to the top of the web page, as well as utilizing a popup style box when loading the login page. This will effectively halt the development of the current milestone and requires team intervention.

Let’s consider that it would require a decent level of effort from the development team. You want to be sure that

1. This feature is something that absolutely takes precedent over the current scope of work 
2. It is going to help deliver a higher-quality, viable product faster.

Depending on the status of the product, this can be a frustrating situation—and bluntly asking “Why” may not be tactful. Instead, we should try to avoid confrontation and dig deeper to better understand the ask and how it will impact the website.

Step one: define the why

This change will halt your team’s production, so we need to get to the bones of why this request warrants the pause. Let’s start by asking some clarifying questions.

Lead with positivity: The important thing to focus on here is that the development team can make the change, our team needs more background information on the significance of the alteration. You need to ensure that it is the right time to make the change, or as I like to say, that the juice is worth the squeeze.

It’s important to iterate that you are going to complete the request, but it’s also important that the stakeholder knows the information provided will help prioritize the new feature and still get the product to market as fast as possible. From here, our whys branch out to gain even more details on the impact of our work.

Step two: refine the why

The next question should always be focused on understanding the “why, or in this case, a clarifying question about the requested feature. “Can you tell me more about the impact you are hoping this will have on your user?”

Make sure to follow it up with a clarifying statement such as, “We are going to be making modifications to the login screen in the coming weeks. This is like what we had talked about based on the user experience.” You’re essentially digging a bit deeper into the justification of the ask while still remaining diplomatic and client-focused.

The stakeholder then responds with, “We need this as soon as possible. It came from our marketing team and when they ask, we can’t say no.”

True as this may be, the client’s response does not get us the information we need. We need to dig into our follow-up why in question two.

Why will this help our release?

A good response could sound like “Okay, great. With that in mind, why do you feel this is going to help us with our stated goal for this feature release? We had previously decided that it was more important to complete the menu navigation.” In this instance, you are reiterating the existing goals for affirmation before altering the plan.

From then, the client may support their need for change by providing analytics on lagging login time impacting the user experience. As a justification, the client proposes moving the button and creating a pop-up for visibility, as it may decrease the time it takes for a user to log in and access their account. Now we are getting somewhere!

But wait…there’s more!

You’re not totally there yet and need to potentially ask one or two more questions. Keep in mind, when using “The 5 Why’s” method, you should look at the issue and ask “Why?” up to 5 times to identify the root cause.

You know that based on analytics provided, the login is where a lot of the paying customers of the website are spending their time. The goal is to get features released that will have the most valuable impact in the shortest amount of time—leading to your minimum viable product (MVP). Your next why should seal the deal.

“That makes a lot of sense. Once a user logs in, the system takes them to their profile page. Should we keep this the same?” Good question. You are thinking ahead to what the user is or should be doing once they are logged in.

Your stakeholder responds “Right. We want them to be able to access their subscriptions page. We have found that now is the time that they want to up their subscription with the changes we are making, and the market is the right time to do it.” And there you go. From what we have right now, we can confirm that the change is, in fact, warranted. Now we need to forge a game plan.

From this statement, we can probe deeper into why these changes will add value to the release.

After meeting with the client (and potentially their marketing SMEs), we discover that the justification for these changes includes:

• The analytics and marketing team have identified the business case for it in that they will be able to get to their user dashboard faster
• Once logged in from the popup menu, it should redirect them immediately to the subscriptions page so that they can update that information

A faster login experience will allow for a timelier update to their account and would thus improve revenue and the bottom line

While the Scrum Master inside you may be screaming “NO! DON’T CHANGE THE SPRINT GOAL! NO NEW WORK! YOU ARE BREAKING THE RULES!” - Let’s take a step back and think about what we are here to do. First and foremost, our goal is to deliver value to our stakeholders and in turn, the end-user.

Confirm and communicate with your team(s)

While this may be disruptive to the team, we are not asking for a complete re-build. We are asking them to shift focus to a different UI feature that will increase revenue in a short amount of time and effort.

Always be sure that the stakeholder understands that within a 2-week sprint period, this could essentially be completed in the next 2-4 weeks.

With that in mind, your final question should confirm the change, but also give the client a timeline for the iteration. And with that, all is right with the world once more. You now understand the client’s needs better, your team has a realistic timeline, and your next feature release is going to add significant value to your sprint.

Note from your Scrum Master: It should be noted that the "5 Whys" is a tool best used over a phone call, Zoom meeting, or face-to-face setting. Because of the need for clear and timely answers, this isn’t an ideal strategy for asynchronous communication (e-mail or instant messenger).

Final thoughts

As human beings, we dread change—especially when it is disruptive to our active processes. The key here is to remember that the focus should always be on delivering a quality feature or product in iterative chunks that will add value to the stakeholder and end-user. By using the 5 Whys root cause analysis tool, we can focus on the stakeholder’s needs while supporting our team through clear, value-driven iterations.