Ir al contenido

Five Whys

De Scrum Manager BoK
Esta página es una versión traducida de la página Cinco veces porqué. La traducción está completa al 100 %.
⏱ 3 min  ·  📅 2026
Five Whys (Cinco veces porqué in Spanish) is a root cause analysis technique used during the retrospective to identify why a particular problem has occurred. It consists of asking "why?" iteratively up to five times, digging deeper into each answer until reaching underlying causes that are not obvious at first sight.

It was developed by Sakichi Toyoda and is part of the Toyota Production System (TPS). In agile retrospectives, it is commonly used in the third phase, which is devoted to generating insights about what happened during the sprint. It takes 15 to 20 minutes and is done in pairs or small groups.

When to use it

  • When the team has identified a recurring or significant problem and wants to understand its causes before proposing solutions.
  • After data-gathering activities such as Patterns and shifts, which identify what happened; the Five Whys help to understand why it happened.
  • When the solutions the team usually proposes are always the same and do not solve the underlying problem.

How to apply it

  1. The team has previously identified the problems it wants to analyze.
  2. Pairs or small groups are formed. Each group focuses on a specific problem.
  3. One person asks "why?" and another answers. The questioning continues, asking "why?" about each answer, up to five times.
  4. The goal is to reach causes that lie outside the usual way of thinking about the problem. The fourth and fifth whys are the most revealing: they tend to point to systemic or cultural causes, not immediate ones.
  5. Each group writes down the answers that emerged from the fourth and fifth whys.
  6. At the end, the groups share their findings to use them in the next phase of the retrospective.

Practical example

Problem: "We delivered the payments feature late."

  • Why? → Because testing took longer than expected.
  • Why? → Because there were many edge cases that hadn't been considered.
  • Why? → Because the acceptance criteria didn't specify them.
  • Why? → Because refinement was rushed the week before.
  • Why? → Because we have no protected time for refinement during the sprint.

The root cause is not "the tests took longer" but "there is no protected time for refinement." The solution is different, too.

How to facilitate it

The activity should focus on events, behaviors, and processes, not on people. The goal is a constructive analysis of systemic causes, not the assignment of blame. The facilitator should step in if the conversation drifts toward pointing at a specific person.

Common mistake

Stopping at the second or third why. The first answers to "why?" tend to be immediate, obvious causes, not root causes. The value of the technique lies in continuing to ask beyond the point of comfort: the systemic causes that deserve action usually emerge at the fourth or fifth why. Stopping earlier means reaching conclusions the team already knew.

Resources

🔧 Diseñar una retrospectiva [Designing a retrospective, in Spanish]Template · Scrum Manager

📄 Tercera fase de una retrospectiva: crear conocimiento [Third phase of a retrospective: generating insights, in Spanish]Scrum Manager Blog · Oct 2023

References

  • Derby, Esther; Larsen, Diana. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
  • Ohno, Taiichi. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.

See also

Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.