Por qué 2/3 de los elementos de acción de retrospectivas mueren (y cómo solucionarlo)

El Turno del Cementerio

Imagina esto: Es hora de la retrospectiva del sprint. El equipo se reúne, ya sea en persona o disperso en pantallas de video. Vuelan las notas adhesivas. Alguien menciona el cuello de botella en el despliegue que ha estado matando la velocidad. Otra persona menciona la suite de pruebas inestable. Un tercero sugiere rotaciones de programación en pareja para difundir el conocimiento.

Al final de la sesión, tienes una lista ordenada de elementos de acción:

• "Investigar paralelización de CI" — asignado a Sarah
• "Documentar el flujo de autenticación" — asignado a Mike
• "Configurar calendario de rotación para revisiones de código" — asignado al líder del equipo

Todos asienten. La retro termina. La gente se siente bien. Se logró progreso.

Dos semanas después, misma sala, mismas caras. Nueva retro. Y nadie menciona qué pasó con esos elementos de acción. Porque no pasó nada con esos elementos de acción. Murieron en silencio, en algún lugar entre el backlog de Jira y las buenas intenciones de todos.

¿Te suena familiar?

Las Matemáticas Incómodas

Aquí hay una estadística que debería perseguir a cada scrum master: Una encuesta de la comunidad del PMI encontró que casi dos tercios de los equipos implementaron menos del 25% de las ideas de mejora de su última retrospectiva. Ni un solo encuestado dijo haber implementado más del 75%.

Lee eso de nuevo. Dos tercios de los equipos ni siquiera pueden ejecutar una cuarta parte de lo que se comprometieron a hacer.

Esto no es una ineficiencia menor del proceso. Es una crisis masiva de credibilidad. Cada elemento de acción abandonado es una pequeña promesa rota. Acumula suficientes de esas y obtienes "fatiga de retrospectivas" — esa vibra cínica y desconectada donde la gente deja de molestarse en plantear problemas porque ha aprendido que nada cambia de todos modos.

La ceremonia continúa. La mejora no.

¿Por Qué Mueren los Elementos de Acción de las Retrospectivas?

Los elementos de acción de las retrospectivas mueren porque el sistema está diseñado para el fracaso, no porque la gente sea perezosa o no le importe. Nada obliga al equipo a confrontar compromisos antiguos, los estados "en progreso" ocultan el abandono, los elementos olvidados desaparecen sin una decisión, y admitir una promesa rota es lo suficientemente incómodo como para que nadie lo mencione. Cuatro problemas, un cementerio.

Problema 1: Sin Función Forzosa

Los elementos de acción tradicionales viven en Jira o un documento compartido o las notas de alguien. Compiten con el trabajo real del sprint por atención. ¿Y adivina qué gana cuando el product owner pregunta sobre la fecha límite de esa funcionalidad? No "investigar paralelización de CI".

No hay un momento en que el equipo se vea obligado a confrontar el destino de compromisos anteriores. La retro se enfoca en lo que pasó este sprint, no en lo que prometimos el sprint pasado.

Problema 2: Teatro del Progreso

Muchas herramientas te permiten marcar elementos de acción como "en progreso" o "50% completo" o cualquier porcentaje que te haga sentir productivo. Esto es una trampa. Un elemento de acción que ha estado "en progreso" durante tres sprints no está en progreso. Está abandonado con pasos adicionales.

El teatro del progreso permite a los equipos evitar el binario incómodo: ¿Hicimos esto o no?

Problema 3: Olvido Silencioso

El destino más común para un elemento de acción no es la finalización o el cierre explícito. Es simplemente ser olvidado. Se desliza hacia el fondo de la lista, reemplazado por compromisos más nuevos y brillantes. Nadie dice "no vamos a hacer esto". Simplemente... deja de existir.

Esto es muerte por negligencia, y es mucho más común que el fracaso explícito.

Problema 4: Evitar la Vergüenza

Seamos realistas: admitir que no hiciste algo a lo que te comprometiste es incómodo. La naturaleza humana es evitar esa conversación. Así que no mencionamos los elementos de acción antiguos. Nos enfocamos en los nuevos problemas. El ciclo continúa.

La Solución Molestamente Efectiva

Cuando construimos el sistema de elementos de acción en Simyl Flow, lo diseñamos para ser intencionalmente incómodo. No cruel — solo honesto. Así es como se ve:

La Verificación de Responsabilidad

La verificación de responsabilidad es una función forzosa: no puedes iniciar una nueva retrospectiva sin primero lidiar con tus compromisos antiguos.

Cuando abres una nueva retro, antes de ver el tablero, antes de que alguien agregue una sola tarjeta, aparece un diálogo. Muestra cada elemento de acción abierto de retrospectivas anteriores. Para cada uno, tienes exactamente tres opciones:

1. Marcar como Hecho — Lo hiciste. Celebra. Sigue adelante.
2. Llevar Adelante — No lo hiciste, pero aún quieres hacerlo. Se transfiere a esta retro con un contador.
3. No Hacer — Estás decidiendo conscientemente no hacer esto. Tienes que decir por qué.

Sin cuarta opción. Sin "en progreso". Sin "hablemos de esto después". Debes decidir.

type ActionDecision = "done" | "carry_forward" | "wont_do" | null;

Eso es todo. Tres estados. Resultados binarios con una salida de escape que requiere explicación.

El Contador de la Vergüenza

Aquí es donde se pone interesante. Cuando llevas una acción adelante, incrementamos un contador.

Este contador es visible. Cuando un elemento de acción muestra "Llevado adelante 2x" en esa insignia ámbar, todos pueden verlo. No son metadatos ocultos. Es una señal pública que dice "hemos pospuesto este compromiso dos veces ya".

¿Es esto un poco incómodo? Sí. Ese es el punto. La incomodidad crea presión para hacer la cosa o decidir conscientemente no hacerla. Ambos son resultados legítimos. La negligencia silenciosa no lo es.

Hemos visto equipos donde una acción que llega a "Llevado adelante 3x" desencadena una discusión automática: "Bien, esto sigue siendo pospuesto. ¿Realmente queremos hacer esto, o deberíamos simplemente cerrarlo?"

Esa conversación es progreso. Esa conversación casi nunca sucede sin el contador visible.

No Hacer Es una Funcionalidad, No un Fracaso

La mayoría de las herramientas tratan el cierre de un elemento de acción como completarlo. Nosotros separamos explícitamente los dos.

Cuando cierras algo como "no hacer", tienes que proporcionar una razón. "Ya no es relevante" está bien. "Las prioridades cambiaron" está bien. "Nos dimos cuenta de que era una idea tonta" está bien. Pero tienes que articularlo.

Esto no es marcar casillas burocráticas. Es obligar al equipo a tomar una decisión explícita. El cierre consciente es infinitamente mejor que el abandono inconsciente. Una decisión de no hacer algo sigue siendo una decisión. Una decisión crea aprendizaje ("intentamos comprometernos con X pero no pudimos seguir adelante debido a Y").

Olvidar no crea nada.

Hecho o No Hecho

Deliberadamente no implementamos porcentaje de finalización o estados de progreso. Un elemento de acción está abierto o hecho. Ese es el modelo de datos:

export type ActionItemStatus = "open" | "done"; // Simplified - done or not done

Esta fue una elección de diseño consciente que hace que algunas personas se sientan incómodas. "¿Qué pasa si estoy a la mitad?" Entonces está abierto. "¿Qué pasa si he comenzado la investigación?" Abierto. "¿Qué pasa si he escrito un borrador?" Todavía abierto.

La única pregunta que importa: ¿Hiciste lo que te comprometiste a hacer?

Este enfoque binario elimina el teatro del progreso por completo. No hay un punto medio cómodo donde puedas reclamar crédito por intenciones. O lo entregaste o no lo hiciste.

Tus Acciones Te Siguen

Construimos un tablero personal — la página "Mis Acciones" — que agrega todos tus elementos de acción en cada equipo en el que estás.

Esto crea una superficie de responsabilidad personal. Tus compromisos no están dispersos en diferentes tableros de retro y proyectos de Jira del equipo. Están todos en un solo lugar, mirándote fijamente.

El efecto psicológico es sutil pero real. Cuando tus acciones abiertas son visibles en tu tablero personal cada vez que inicias sesión, son más difíciles de olvidar. No están enterradas en un backlog del equipo. Están en tu cara.

La Confianza Se Mide, No Se Asume

Aquí es donde el sistema se pone serio. La tasa de finalización de elementos de acción alimenta directamente nuestras métricas de Dinámica de equipo — específicamente, la Puntuación de Confianza.

function calculateActionScore(
  completed: number,
  total: number,
  config: TeamDynamicsConfig,
): number {
  if (total === 0) return 50; // No actions = neutral
  const rate = completed / total;

  // Use config threshold
  if (rate >= config.healthyActionItemCompletion) return 100;
  if (rate >= config.healthyActionItemCompletion * 0.7) return 70;
  return Math.max(20, rate * 100);
}

¿Por qué la finalización de acciones se relaciona con la confianza? Porque el seguimiento es confianza. Cuando un equipo cumple consistentemente con sus compromisos — incluso los internos que solo afectan al equipo — eso construye confianza. Por el contrario, un patrón de promesas rotas (incluso pequeñas como elementos de acción de retro) erosiona la confianza del equipo en sí mismo.

Un equipo que no puede confiar en sus propios compromisos tendrá dificultades con todo lo demás.

La métrica no es punitiva. Un equipo que no crea elementos de acción obtiene una puntuación neutral. Un equipo que crea algunos y completa la mayoría es recompensado. Un equipo que crea muchos y completa pocos es señalado — no como "malo" sino como una señal de que algo está mal. Tal vez las acciones son demasiado ambiciosas. Tal vez no hay tiempo reservado para el trabajo de mejora. Tal vez el problema es sistémico.

La métrica crea la conversación. El equipo decide qué hacer al respecto.

La Filosofía

Todo lo que construimos aquí proviene de una creencia simple: las decisiones explícitas superan la negligencia implícita.

• Decir "no haremos esto" es mejor que olvidarlo silenciosamente.
• Decir "estamos llevando esto adelante" es mejor que pretender que no nos comprometimos.
• Decir "lo hicimos" (cuando realmente lo hiciste) es mejor que "hicimos algo de progreso".

No estamos tratando de avergonzar a los equipos. Estamos tratando de crear un sistema donde la honestidad sea más fácil que la evasión. Donde el camino de menor resistencia conduzca a la claridad en lugar de la ambigüedad.

Las herramientas tradicionales hacen que sea fácil olvidar e incómodo confrontar. Lo volteamos. Nuestro sistema hace que olvidar sea imposible (la verificación de responsabilidad) y la confrontación manejable (tres opciones claras, cada una legítima).

El resultado no son tasas de finalización del 100%. Eso sería poco realista y probablemente indicaría que los equipos solo se comprometen con acciones seguras y fáciles. El resultado son equipos que conocen el destino de cada compromiso que hicieron. Eso es algo muy diferente, y es mucho más valioso.

Lo Que Hemos Visto

Los equipos que usan el patrón de verificación de responsabilidad reportan algunos cambios consistentes:

Menos Acciones, Mejores Acciones

Cuando sabes que serás confrontado con tus compromisos, haces menos de ellos. Pero los que haces son más propensos a ser cosas que realmente harás. El patrón de "pongamos esto en la lista de elementos de acción para que la gente se sienta escuchada" muere rápido.

Decisiones de No Haremos Más Rápidas

Los equipos mejoran en reconocer cuándo algo no va a suceder. En lugar de dejarlo persistir durante tres sprints, lo cerrarán en uno o dos. "Dijimos que haríamos esto, no lo hemos hecho, no lo haremos — cerrémoslo y dejemos de pretender".

Más Conversaciones de Confianza

Cuando la puntuación de Dinámica de equipo refleja el seguimiento de elementos de acción, se convierte en datos para la retrospectiva misma. "Nuestra puntuación de confianza bajó este sprint. Un factor: solo completamos 2 de 7 elementos de acción. ¿Qué está pasando?"

Esa meta-conversación sobre la capacidad del equipo para cumplir con los compromisos es a menudo más valiosa que cualquier elemento de acción individual.

Intenta Estar Incómodo

Si tus elementos de acción de retro siguen muriendo, el problema no es la motivación. Es el diseño del sistema. Necesitas:

1. Una función forzosa — Algo que haga que confrontar viejos compromisos sea obligatorio, no opcional.
2. Resultados binarios — Hecho o no hecho. Sin esconderse detrás de porcentajes.
3. Seguimiento visible de lo que se lleva adelante — Un contador que hace visible el aplazamiento repetido.
4. Cierre legítimo — Una opción de "no haremos" que requiere una razón pero se trata como válida.
5. Superficies de responsabilidad personal — Tus compromisos te siguen, no solo al equipo.
6. Métricas que reflejan la realidad — El seguimiento afecta las puntuaciones de salud del equipo.

Construimos todo esto en Simyl Flow porque nos cansamos de ver morir buenas ideas de mejora en el espacio entre reuniones. La verificación de responsabilidad es un poco molesta. El contador de lo que se lleva adelante es un poco incómodo. El estado binario es un poco rígido.

Ese es el punto. La comodidad es como mueren los elementos de acción.

Fuentes

1. Bondale, K. (2022). "Why hold retrospectives if ideas don't get implemented?" — PMI "Easy in theory, difficult in practice" blog
2. Wolpers, S. (2024). "Ditch the Unfinished Action Items – How to Make Retrospectives Lead to Real Change"