agile top banner

The 5 Whys Approach To Root Cause Analysis In Agile Teams

Read it in 5 Mins

Last updated on
01st Jul, 2022
30th Jun, 2017
The 5 Whys Approach To Root Cause Analysis In Agile Teams

Socrates once said ‘I know that I know nothing’. Well, he didn't mean that he actually didn't know anything or that he was absolutely ignorant, but he inferred the fact that there’s much more to learn if he questioned it and dug in deeper. You would uncover deep-seated truths about constructs from the context and on why they exist and interact as they do. This is fundamentally how everything in this world works.

This phenomenon can be seen at the workplace as well. Especially when the project manager or scrum master enforces his team to do a root cause analysis. In other words, he asks them to retrospect on why certain things happened. Haven’t you experienced the same? 

Now, let’s talk a bit about root cause analysis.

Root Cause Analysis is a methodology used for analyzing problems in order to identify the main reason for that problem. It is an approach taken for problem analysis and interrogation. This is exactly what Socrates introduced in his Socratic Method. Each time when Agile teams practices any effective root cause analysis techniques, Socrates must be looking down from heaven smiling away.

Get to know more about agile vs traditional project management.

Root cause analysis can take many forms. Ishikawa or Fishbone diagram, 5 Whys approach to naming he most common.This article is not to talk about root cause analysis as a concept but to discuss how Agile teams can use use the 5 whys to identify the root cause analysis process.

Introduction to 5 Whys or the Why-Why Analysis:

This approach was first introduced by Sakichi Toyoda, the founder of Toyota Motor Corporation. The technique was used in the vehicle manufacturing plants to evaluate why problems occur during the production process. Often when a defect or an issue occurred, the team used to give a temporary solution, patch the problem and move on. However, the same problem used to resurface. Toyoda understood that the root cause was not being addressed in the solution given and only the symptoms were being addressed. Thus he formulated the 5 Whys technique to explore problems at hand.

As the name suggests, 5 Why’s is a process of asking Why 5 times to get to the root of a certain problem. However, 5 is not the minimum or maximum number of times you should ask ‘Why’.

An example of why-why analysis for Agile teams would be something as follows:





  • Why did the user complain that notifications didn’t go out when he added a new customer to the CRM?

           Because there was a bug in the last release

  • Why was there a bug in the last release?

           Because we didn’t test this scenario

  • Why didn’t we test this scenario?

           Because we only tested the features developed during the last sprint. We didn’t do a regression test on all the features in the application.

  • Why didn’t you test all the features in the application?

          Because notifications feature was something built a long time ago and it’s not practical to test all the app features in every release.

  • Why is it not practical to test all features in the application during every release?

         The application is now so big that performing regression testing on every feature at the end of each sprint is time-consuming.

As we can see, this process helps you get a better picture of the underlying cause of the problem. We will now be able to go beyond the traditional answer of ‘We missed a bug’ or ‘Our bad, we will test the application thoroughly next time’ type of answer. The is simply because we now know the primary cause that needs to be addressed is to do with regression testing. We simply identified that testing is an issue, but it is not the root cause of the issue.

How the 5 Whys approach helps

The 5 Whys approach lets you determine what you should do to rectify the situation. It helps you make a decision on what action to take, whom to consult, what sort of effort is required and so on. In the above scenario it will help us identify the regression processes for the project, what tools to use, and help decide whether to automate regression testing activities.

We can see that 5 why’s is a great tool for agile teams to use. There’s no set standard or guideline on how to use it. It’s up to the team to decide when to use it and how. It doesn’t need to be 5 why’s as explained earlier but just be done to an extent which allows you to make a concrete assessment and decision. Get everyone impacted or interested involved in the process and perform it diligently.

Ever thought why a 5 or 6 year old child keeps on asking why? Isn’t it sometimes annoying? ‘Why is that car red?’, ‘Why does that dog bite?’. These are some annoying questions a child may ask for which you may sometimes have no answer. Isn’t it more irritating when the child keeps on asking why for each answer you give?

Success factors for Root Cause Analysis

There are many different approaches to find the root cause of problems. You can perform a general problem analysis with one or more professionals and demonstrate the results to those involved to deal with and refine them. For smaller issues, you can follow the 5 Whys technique discussed above. 

Analyzing the error that has been found during testing or stated by customers helps to enhance your product quality. Agile teams can perform root cause analysis in the retrospective meetings or can have separate meetings they analyze carefully by asking why. It is essential to perform root cause analysis irrespective of the technique that is used to get business value out of it. 

Final Thoughts

Finally, my concluding remark is to invite you to call forth your inner child again. Ask Why how stupid or trivial it may be. Remember, we only see the tip of the iceberg. There’s lots more of the problem that we have forgotten to explore or ignored to accept!


Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin