Idioma: Español
Probar gratis 14 días

Skill oficial · Gestión de equipos

Retrospectiva de equipo

v1.0.1 · Actualizada el

Conduce una retro de equipo a partir de notas o una encuesta: temas, causas raíz con los 5 porqués y de 1 a 3 experimentos con responsable y fecha de revisión.

Agregar al pod de mi equipo Descargar SKILL.md

Funciona en Claude, ChatGPT y agentes de programación. En Team y Business, la skill oficial de tu pod se actualiza sola cuando la mejoramos.

Cuándo usarla

Qué le das

Qué obtienes

Un resumen de la retro con las acciones anteriores revisadas, temas con recuentos, causas raíz y hasta 3 experimentos con responsable.

Cómo funciona

  1. Revisa primero las acciones de la retro anterior Cada una: hecha, no hecha o descartada, con una línea sobre lo que pasó. Si más de la mitad no se hicieron, el primer experimento de esta vez es tener menos acciones y más pequeñas.
  2. Elige el formato Salió bien / no salió bien / probar la próxima vez para la mayoría de los equipos. Empezar / Dejar / Continuar (Start / Stop / Continue) cuando el equipo necesita cambiar comportamientos. Las 4L (lo que nos encantó, lo que odiamos, lo que aprendimos, lo que extrañamos; en inglés loved, loathed, learned, longed for) cuando el periodo trajo mucho aprendizaje, como un primer lanzamiento. No mezcles formatos en una misma retro.
  3. Agrupa el material en temas Une los duplicados y cuenta cuántas personas mencionaron cada tema. Busca patrones que se repiten, no hechos aislados. Para los temas principales, conserva entre comillas las palabras de los participantes; anonimiza los nombres salvo que el material ya venga firmado.
  4. Encuentra la causa raíz de los 2 problemas principales Pregunta “¿por qué?” hasta llegar a algo que el equipo pueda cambiar. El Lean Enterprise Institute, que atribuye el método a Taiichi Ohno en Toyota, dice que el número 5 no es lo importante. Detente si llegas a una causa fuera del control del equipo, y dilo. Nunca te detengas en una persona (“Sam se olvidó”): pregunta por qué el proceso permitió que se olvidara.
  5. Elige de 1 a 3 experimentos Cada uno es un cambio concreto para el próximo periodo, lo bastante pequeño para probarlo, con un responsable (una persona), una fecha para revisarlo y cómo sabremos que funcionó. Si el equipo propone 8 acciones, quédate con las 3 de mayor efecto esperado y deja el resto en espera.
  6. Planifica la sesión si es en vivo Para 60 minutos, el Team Playbook de Atlassian la reparte así: crear el clima (5), recoger aportaciones (15), encontrar patrones (20), elegir acciones (15), cerrar (5). Recuerda a todos que el objetivo es mejorar, no buscar culpables.

El SKILL.md

El archivo completo, tal como lo lee tu IA. Descargarlo

---
name: retrospective
description: Conduce una retrospectiva de equipo a partir de notas, post-its o una encuesta: qué salió bien, qué no, patrones que se repiten, causas raíz con unos breves 5 porqués y de 1 a 3 experimentos con un responsable y una fecha cada uno, en formato Empezar/Dejar/Continuar, 4L o salió bien/no salió bien. Úsala cuando un equipo pide conducir o redactar una retro, una retrospectiva de sprint, una revisión al cerrar un proyecto, lecciones aprendidas o “qué cambiamos la próxima vez”.
---

# Retrospectiva de equipo

Una retro vale la hora que cuesta solo si el próximo sprint o proyecto funciona de otra manera. La Guía de Scrum lo plantea como planificar “formas de aumentar la calidad y la efectividad”. Así que el resultado no es una lista de sensaciones: son de 1 a 3 cambios que el equipo va a probar, cada uno con un responsable y una fecha, y antes que nada se revisan los cambios de la retro anterior.

## Cuándo usarla

- Al final de un sprint, un proyecto, un lanzamiento o un trimestre.
- Cuando un equipo tiene material en bruto (respuestas de una encuesta, post-its, un hilo de Slack) y necesita agruparlo en temas y acciones.
- Para preparar el plan de quien facilita antes de hacer la sesión en vivo.
- No sirve para un incidente puntual con impacto en clientes: en ese caso, redacta una revisión del incidente con su cronología.

## Qué necesitas

- El material en bruto: notas, respuestas de la encuesta o la exportación de un tablero. Si no hay nada, prepara el plan de facilitación y la plantilla vacía.
- El periodo o el proyecto que se revisa, y quién participó.
- Las acciones de la retro anterior, si las hay. Si faltan, escribe “no hay acciones anteriores registradas”.
- El formato preferido. Si no hay ninguno, usa salió bien / no salió bien / probar la próxima vez (el valor por defecto de esta skill; es el más sencillo).

## Pasos

1. **Revisa primero las acciones de la retro anterior.** Cada una: hecha, no hecha o descartada, con una línea sobre lo que pasó. Si más de la mitad no se hicieron, el primer experimento de esta vez es tener menos acciones y más pequeñas.
2. **Elige el formato.** Salió bien / no salió bien / probar la próxima vez para la mayoría de los equipos. Empezar / Dejar / Continuar (Start / Stop / Continue) cuando el equipo necesita cambiar comportamientos. Las 4L (lo que nos encantó, lo que odiamos, lo que aprendimos, lo que extrañamos; en inglés loved, loathed, learned, longed for) cuando el periodo trajo mucho aprendizaje, como un primer lanzamiento. No mezcles formatos en una misma retro.
3. **Agrupa el material en temas.** Une los duplicados y cuenta cuántas personas mencionaron cada tema. Busca patrones que se repiten, no hechos aislados. Para los temas principales, conserva entre comillas las palabras de los participantes; anonimiza los nombres salvo que el material ya venga firmado.
4. **Encuentra la causa raíz de los 2 problemas principales.** Pregunta “¿por qué?” hasta llegar a algo que el equipo pueda cambiar. El Lean Enterprise Institute, que atribuye el método a Taiichi Ohno en Toyota, dice que el número 5 no es lo importante. Detente si llegas a una causa fuera del control del equipo, y dilo. Nunca te detengas en una persona (“Sam se olvidó”): pregunta por qué el proceso permitió que se olvidara.
5. **Elige de 1 a 3 experimentos.** Cada uno es un cambio concreto para el próximo periodo, lo bastante pequeño para probarlo, con un responsable (una persona), una fecha para revisarlo y cómo sabremos que funcionó. Si el equipo propone 8 acciones, quédate con las 3 de mayor efecto esperado y deja el resto en espera.
6. **Planifica la sesión si es en vivo.** Para 60 minutos, el Team Playbook de Atlassian la reparte así: crear el clima (5), recoger aportaciones (15), encontrar patrones (20), elegir acciones (15), cerrar (5). Recuerda a todos que el objetivo es mejorar, no buscar culpables.

## Formato de salida

```markdown
# Retro — [equipo / proyecto], [periodo]

**Formato:** [salió bien / no salió bien / probar | Empezar/Dejar/Continuar | 4L]
**Participantes:** [nombres o número]

## Acciones de la retro anterior
| Acción | Responsable | Estado | Qué pasó |
|---|---|---|---|
| [acción] | [nombre] | hecha / no hecha / descartada | [una línea] |

## Qué salió bien
- [Tema] — lo mencionaron [n] — “[cita representativa]”

## Qué no salió bien
- [Tema] — lo mencionaron [n] — “[cita representativa]”

## Causas raíz
**[Problema 1]**
- ¿Por qué? [respuesta] → ¿Por qué? [respuesta] → ¿Por qué? [respuesta] → causa raíz: [algo que el equipo puede cambiar]

## Experimentos para el próximo [sprint / proyecto]
| Experimento | Responsable | Se revisa el | Sabremos que funcionó si |
|---|---|---|---|
| [cambio concreto] | [nombre] | [fecha] | [señal observable] |

## En espera
- [Ideas no elegidas esta vez]
```

## Ejemplo

**Entrada:** “Equipo de Plataforma, retro del Sprint 14, 6 personas (PM: Lina), respuestas de la encuesta: «La demo salió genial» (3), «Programar en pareja el importador ayudó» (2), «Demasiados cambios de alcance de última hora» (4), «QA recibió la build el jueves, sin tiempo para probar» (3), «Las dailies duran 25 min». Acción de la retro anterior: «Ana configura un entorno de staging» — hecha, en marcha desde el día 3. De la conversación: las historias se terminaron en los últimos 2 días; los cambios de alcance tardíos hicieron reiniciar 2 historias; las peticiones que llegan después de la planificación van directamente a los desarrolladores”.

**Salida:**

```markdown
# Retro — Equipo de Plataforma, Sprint 14

**Formato:** salió bien / no salió bien / probar
**Participantes:** 6

## Acciones de la retro anterior
| Acción | Responsable | Estado | Qué pasó |
|---|---|---|---|
| Configurar un entorno de staging | Ana | hecha | En marcha desde el día 3 |

## Qué salió bien
- La demo del sprint — lo mencionaron 3 — “La demo salió genial”
- Programar en pareja el importador — lo mencionaron 2

## Qué no salió bien
- Cambios de alcance tardíos — lo mencionaron 4 — “Demasiados cambios de alcance de última hora”
- QA apretado al final — lo mencionaron 3 — “QA recibió la build el jueves, sin tiempo para probar”
- Dailies largas — lo mencionó 1

## Causas raíz
**QA apretado al final**
- ¿Por qué? La build llegó a QA el jueves → ¿Por qué? Las historias se terminaron en los últimos 2 días → ¿Por qué? Los cambios de alcance tardíos hicieron reiniciar 2 historias → ¿Por qué? Las peticiones posteriores a la planificación van directamente a los desarrolladores → causa raíz: no hay ninguna regla para los cambios después de la planificación del sprint.

## Experimentos para el próximo sprint
| Experimento | Responsable | Se revisa el | Sabremos que funcionó si |
|---|---|---|---|
| Los cambios después de la planificación pasan por la PM, que saca otra cosa a cambio | Lina (PM) | Retro del Sprint 15 | Ninguna historia se reinicia a mitad de sprint |
| QA recibe la build al menos 2 días antes de que termine el sprint | Ana | Retro del Sprint 15 | QA reporta 2 días o más para probar |

## En espera
- Dailies más cortas (se mencionó una vez; retomarlo si vuelve a salir)
```

## Comprobaciones antes de enviar

- [ ] Las acciones de la retro anterior tienen un estado antes de que aparezca cualquier acción nueva.
- [ ] 3 experimentos o menos, cada uno con un responsable con nombre, una fecha de revisión y una señal de éxito.
- [ ] Cada cadena de causa raíz termina en algo que el equipo puede cambiar, no en el nombre de una persona.
- [ ] Los recuentos de los temas coinciden con la entrada; no se cita nada que no se haya dicho.
- [ ] Los comentarios individuales son anónimos salvo que la entrada viniera firmada.

## Errores comunes

- Terminar con “comunicarnos mejor”. Nombra el cambio: quién hace qué de otra manera y desde cuándo.
- Escribir 10 acciones. Los equipos terminan de 1 a 3; el resto desgasta la confianza en la retro.
- Saltarse lo que salió bien. Le dice al equipo qué proteger cuando cambie cosas.

Compártela con tu equipo

Agrégala a un AI Skill Pod y todo el equipo, colaboradores externos incluidos, usa la misma versión desde su propia IA. Lee las mejores formas de compartir skills de IA con un equipo

Agregar al pod de mi equipo

Historial de cambios

Fuentes

  1. Sprint Retrospective: How to Hold an Effective Meeting - Atlassian (leída el 2026-11-04)
  2. The Scrum Guide (leída el 2026-11-04)
  3. 5 Whys - What is it? - Lean Enterprise Institute (leída el 2026-11-04)