Cinco veces porqué

⏱ 3 min de lectura  ·  📅 Actualizado en 2026

Cinco veces porqué (Five Whys en inglés) es una técnica de análisis de causa raíz que se usa durante la retrospectiva para identificar por qué se ha producido un determinado problema. Consiste en preguntar "¿por qué?" de forma iterativa hasta cinco veces, profundizando en cada respuesta hasta llegar a causas subyacentes que no son evidentes a primera vista.

Fue desarrollada por Sakichi Toyoda y es parte del Sistema de Producción Toyota (TPS). En retrospectivas ágiles se usa habitualmente en la tercera fase, dedicada a generar conocimiento sobre lo ocurrido durante el sprint. Dura entre 15 y 20 minutos y se trabaja en parejas o grupos reducidos.

Cuándo usarla

• Cuando el equipo ha identificado un problema recurrente o significativo y quiere entender sus causas antes de proponer soluciones.
• Después de actividades de recopilación de datos como Patterns and shifts, que identifican qué ha pasado; los Cinco porqués ayudan a entender el por qué.
• Cuando las soluciones que el equipo suele proponer son siempre las mismas y no resuelven el problema de fondo.

Cómo aplicarla

1. El equipo ha identificado previamente los problemas que quiere analizar.
2. Se forman parejas o grupos pequeños. Cada grupo se centra en un problema concreto.
3. Una persona pregunta "¿por qué?" y otra responde. Se continúa preguntando "¿por qué?" sobre cada respuesta, hasta cinco veces.
4. El objetivo es llegar a causas que estén fuera de la manera habitual de pensar sobre el problema. Los porqués cuarto y quinto son los más reveladores: suelen apuntar a causas sistémicas o culturales, no a causas inmediatas.
5. Cada grupo apunta las respuestas surgidas del cuarto y quinto porqué.
6. Al terminar, los grupos comparten sus descubrimientos para usarlos en la siguiente fase de la retrospectiva.

Ejemplo práctico

Problema: "Entregamos tarde la funcionalidad de pagos".

• ¿Por qué? → Porque los tests tardaron más de lo previsto.
• ¿Por qué? → Porque había muchos casos de borde no contemplados.
• ¿Por qué? → Porque los criterios de aceptación no los especificaban.
• ¿Por qué? → Porque el refinamiento se hizo con prisas la semana anterior.
• ¿Por qué? → Porque no tenemos tiempo protegido para el refinamiento en el sprint.

La causa raíz no es "los tests tardaron" sino "no hay tiempo protegido para el refinamiento". La solución también es diferente.

Cómo moderarla

La actividad debe centrarse en acontecimientos, comportamientos y procesos, no en personas. El objetivo es el análisis constructivo de causas sistémicas, no la asignación de culpas. El facilitador debe intervenir si la conversación deriva hacia señalar a alguien en concreto.

Error frecuente

Quedarse en el segundo o tercer porqué. Las primeras respuestas a "¿por qué?" suelen ser causas inmediatas y obvias, no causas raíz. El valor de la técnica está en seguir preguntando más allá de lo cómodo: las causas sistémicas que merecen acción suelen aparecer en el cuarto o el quinto porqué. Parar antes es llegar a conclusiones que el equipo ya conocía.

Recursos

📄 Tercera fase de una retrospectiva: crear conocimientoScrum Manager Blog · oct 2023

Referencias

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.

Véase también

Retrospectiva Fishbone Patterns and shifts Brainstorming/Filtering Force field analysis Acuerdos de trabajo

¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.

Buscar convocatorias

Club Agile