Product Management

Building Better Software Teams Part 2 - Starting with 5 Whys

Prashant Bhargava

20 Oct 2025 — 5 min read

In Part 1, we explored the story of Beth and her team, who are facing challenges in delivering a critical project on time. We observed Beth taking initiative by speaking with her manager, Linda, to bring the team together and discuss their current predicament. Additionally, we saw them identify 6 primary reasons they believe are affecting the team’s productivity.

The team reconvenes the following day, determined to get to the bottom of these issues. They begin by applying the 5 Whys technique to each problem to identify their root causes.

5 Whys

The 5 Whys technique, devised by Sakichi Toyoda at Toyota in the 1930s, was created to address recurring issues in the manufacturing process. By repeatedly asking “Why?” — typically five times — Toyota aimed to move beyond surface-level symptoms and uncover the root cause of problems like equipment failures or production inefficiencies. This method, central to the Toyota Production System, became widely adopted for its effectiveness in promoting deep analysis and preventing superficial fixes in various industries.

Linda recommends starting with the most critical issue. The team unanimously agree that discovering or adding more work mid-sprint is problematic. It disrupts their focus and sprint estimates, necessitating constant re-prioritization of new tasks alongside planned work. This also negatively affects team morale.

Concern 1. The team keeps discovering more work during the sprint.

Why?

Because we often underestimate the complexity of tasks during sprint planning.

Why?

Because the scope outlined in tickets is overly simplistic compared to the actual work required to achieve the desired outcome.

Why?

Our tickets are created based on the complete user journey, typically involving work on 5–6 different screens. Capturing all this information in a single ticket is impractical, so the ticket gives an overview of the work and references the designs.

Why?

Because we aim to complete as many user journeys as possible within a single sprint.

Why?

To enable parallel development and meet our deadlines.

This revelation is an eye-opener for the team. They recognize how their strategy of attempting to complete multiple user journeys in a single sprint is counterproductive. Rather than successfully completing multiple journeys, developers working in isolation are actually compounding problems.

Upon further discussion, they identify several drawbacks to this approach:

Since the scope of a single ticket is large, their merge requests (MRs) are gigantic. Giant MRs mean longer review time.
This results in knowledge gaps within the team. Developers are only familiar with their code and unaware of potential interactions with other features, potentially causing unexpected behaviors and bugs.
Addressing an entire journey means issues often go unnoticed until the midpoint of the sprint, which is typically when developers fully grasp the scope of their task. This is the main reason why they see so many additional tickets being created mid-sprint.
At this point, the designer also chimes in and mentions how this approach contributes to delays in providing designs to the team. Working on multiple user journeys simultaneously prevents prioritizing a single journey, loss of focus and creating uncertainty about which designs to focus on next.

The team is pleased to gain a deeper understanding of this issue and decides to reevaluate their ticket creating and sprint planning process.

Resolution

The team decides to apply the fundamental principle of Prioritization to enhance the focus of their sprint.

Rather than developing multiple user journeys simultaneously, the team requests the Product Manager’s assistance in prioritizing them based on their importance. This approach will allow the team to concentrate on the most crucial aspects of the project initially.
They also resolve to limit their focus to 2–3 user journeys per sprint, ensuring the team has a clear objective to complete them.
Instead of developing several journeys in parallel, they opt to break down a single journey into multiple tickets, allowing multiple developers to contribute to a single journey concurrently. This strategy will enable collaboration, reduce the complexity of merge requests, and guarantee a clear deliverable within a single sprint.

This was a brief introduction to the 5 Whys technique and its utility in uncovering the root cause of a problem. Don’t be misled by the number 5, though. It’s not a strict rule that you must ask “Why” exactly 5 times. However, asking “Why” 5 times often provides a sufficient understanding of the issue. If you’re still uncertain, feel free to continue asking “Why” until you either gain the necessary insight or reach a point where further information is not available.

In the next part, we will delve into all the remaining concerns of the team, apply the 5 Whys to each one, and then explore how they approach remediation of these issues.

As we prepare to uncover more insights into effective problem-solving, I would like to invite you to reflect on your own experiences. 🙂

Have you faced similar challenges in your projects?
How did you identify and address them?

Share your stories and strategies in the comments below or on our social media platforms. Your insights could provide valuable perspectives and inspire others in their journey to building better software teams. Stay tuned for the next installment, where we’ll continue to learn and grow together!