¿Qué son los Three Amigos?

Three Amigos (o "Los Tres Amigos") es una práctica de desarrollo de software ágil en la que tres perspectivas distintas (Negocio, Desarrollo y Pruebas) se reúnen para hablar de una funcionalidad antes de construirla y acordar juntas qué significa que esté "terminada". El nombre alude a esos tres puntos de vista, no necesariamente a tres personas concretas: lo importante es que las tres voces estén representadas en la conversación.

El propósito es sencillo y poderoso a la vez: convertir un requisito que vive en la cabeza de una sola persona en un entendimiento compartido por todo el equipo. En lugar de que Negocio escriba una especificación, la lance "por encima del muro" a Desarrollo y luego Pruebas descubra los huecos al final, los tres examinan la misma historia de usuario al mismo tiempo y la convierten en algo concreto, comprobable y sin ambigüedades.

La mayoría de los defectos de software no nacen al programar, sino mucho antes: en un requisito mal entendido, una regla de negocio que nadie explicó o un caso límite que nadie consideró. Cuanto más tarde se detecta ese malentendido, más caro resulta corregirlo.

Los Three Amigos atacan el problema en su origen. Al conversar antes de escribir código, el equipo:

• Descubre supuestos ocultos y reglas de negocio implícitas mientras aún son baratas de aclarar.
• Genera criterios de aceptación claros y consensuados, no impuestos por un solo rol.
• Reduce el retrabajo, las idas y venidas y las preguntas a mitad del sprint.
• Reparte el conocimiento del producto entre varias personas en vez de concentrarlo en una.

No es una reunión más: es una inversión pequeña al principio que evita errores grandes al final.

La sesión suele celebrarse durante el refinamiento del backlog, antes de que una historia entre en un sprint. Es deliberadamente corta (de unos pocos minutos a media hora por historia) e informal. Cada perspectiva aporta una pregunta distinta:

📊 Negocio: ¿qué problema resolvemos?

Representado a menudo por el Product Owner o un analista, aporta el "para qué". Explica la necesidad del usuario, el valor esperado y las reglas de negocio. Su pregunta clave es: ¿qué problema intentamos resolver y por qué?

🛠️ Desarrollo: ¿cómo lo construimos?

Quien va a programar la funcionalidad valora la viabilidad técnica, detecta dependencias y plantea alternativas más simples. Su pregunta clave es: ¿cómo podríamos construir esto y qué nos complica?

🧪 Pruebas: ¿qué podría salir mal?

El perfil de QA aporta el pensamiento crítico: casos límite, escenarios de error y el temido "¿qué pasa si...?". Su pregunta clave es: ¿cómo sabremos que funciona y dónde podría romperse?

De la conversación salen ejemplos concretos que suelen escribirse en formato Dado-Cuando-Entonces, la base de prácticas como BDD. Esos ejemplos se convierten en los criterios de aceptación de la historia y, a menudo, en pruebas automatizadas.

Imagina una historia: "Como usuaria, quiero recuperar mi contraseña por correo".

• Negocio explica que el enlace de recuperación debe caducar para que sea seguro y que el correo debe llegar al instante.
• Desarrollo pregunta qué pasa si la persona pide el enlace varias veces seguidas o si el correo no existe en el sistema.
• Pruebas añade más preguntas: ¿y si el enlace ya caducó? ¿Y si se usa dos veces? ¿Qué mensaje ve quien introduce un email no registrado?

En diez minutos, una historia de una línea se ha transformado en cinco o seis criterios de aceptación verificables. Nadie escribió código todavía y ya se han evitado varias rondas de retrabajo.

• Convertirlo en una ceremonia rígida. No es una reunión larga con acta formal; si se vuelve pesada, el equipo deja de hacerla. Mantenla breve y centrada en la historia.
• Hacerla con todo el equipo a la vez. Bastan tres voces. Reunir a diez personas la diluye y la encarece sin aportar más claridad.
• Confundir los roles con personas fijas. Lo que importa son las tres perspectivas. Una persona con perfil mixto puede representar más de una, y a veces conviene sumar a diseño o a un experto de dominio.
• Tratarla como una entrega de requisitos. No es Negocio "dictando" lo que hay que hacer. Si una sola voz domina, se pierde el sentido: la riqueza está en el diálogo entre las tres.
• Saltársela "porque la historia es fácil". Las historias aparentemente triviales son donde más supuestos ocultos se esconden.

Los Three Amigos encajan de forma natural con varias prácticas del diccionario. Alimentan la Definition of Ready al asegurar que una historia está bien entendida antes de entrar al sprint, y se apoyan en BDD para expresar los ejemplos como escenarios ejecutables. Son una herramienta central del refinamiento del backlog y una de las maneras más eficaces de producir buenos criterios de aceptación dentro de un equipo Scrum o de cualquier enfoque ágil.