Criterios de Calidad

¿Qué estándares de calidad debe cumplir el trabajo para estar terminado?

Todo el código ha sido revisado y aprobado por al menos otro desarrollador.
La cobertura de pruebas unitarias cumple con nuestro umbral acordado del 80% o superior.
No quedan errores críticos o de alta severidad sin resolver.
Documentación y Comunicación

¿Qué debe documentarse o compartirse antes de estar terminado?

La documentación de cara al usuario se ha actualizado para reflejar el cambio.
Las notas de la versión y las entradas del changelog están completas.
La documentación de la API refleja cualquier endpoint nuevo o modificado.
Pruebas y Validación

¿Cómo verificamos que el trabajo realmente funciona?

Se han cumplido todos los criterios de aceptación de la historia de usuario.
Pruebas manuales completadas en los navegadores y dispositivos compatibles.
Funcionalidad validada por el product owner antes de cerrarla.
Despliegue y Preparación

¿Qué debe cumplirse para lanzar el trabajo de forma segura?

La funcionalidad está desplegada en producción o detrás de un feature flag.
La monitorización y las alertas están configuradas para la nueva funcionalidad.
Existe un plan de reversión o recuperación por si algo sale mal.

¿Qué es la Definición de Terminado?

¿Alguna vez has entregado algo solo para descubrir que en realidad no estaba terminado? La Definición de Terminado (DoD, por sus siglas en inglés) aporta claridad a uno de los acuerdos compartidos más importantes que un equipo puede tener. Establece un entendimiento claro y colectivo de los criterios que deben cumplirse antes de que cualquier trabajo —una historia de usuario, una funcionalidad o un sprint completo— pueda considerarse verdaderamente completo. Al hacer explícitas estas expectativas, los equipos reducen el retrabajo, mejoran la calidad y crean un estándar de entrega confiable y repetible. Arraigada en las prácticas ágiles y de Scrum, la Definición de Terminado actúa como una lista de verificación de calidad que todos acuerdan antes de comenzar el trabajo. Elimina las conjeturas de las conversaciones sobre "¿esto está terminado?" y ayuda a los equipos a evitar la trampa de arrastrar trabajo oculto hacia sprints futuros. Ya sea que estés definiendo "terminado" por primera vez o revisando un acuerdo existente, esta sesión colaborativa anima a cada voz a contribuir —desde desarrolladores y testers hasta diseñadores y product owners— para que el resultado refleje la perspectiva de todo el equipo. Ejecutar esta sesión en TeamRetro facilita capturar, discutir, agrupar y priorizar los criterios que más importan a tu equipo. El resultado es un documento vivo que crece con la madurez y los estándares de tu equipo. El resultado es una entrega más predecible, menos sorpresas en la revisión y un sentido compartido de responsabilidad que eleva la calidad de todo lo que entregas. Conoce más sobre el concepto en la <a href="https://www.scrum.org/resources/blog/done-understanding-definition-done" target="_blank" rel="noopener noreferrer">guía de Scrum.org sobre la Definición de Terminado</a>.

Formato de colaboración de Definición de Terminado

Criterios de Calidad

¿Qué estándares de calidad debe cumplir el trabajo para estar terminado?

Este tema captura los estándares técnicos y de calidad que cada pieza de trabajo debe satisfacer antes de considerarse completa. Anima al equipo a pensar en la calidad del código, la cobertura de pruebas, el rendimiento y los estándares. Haz preguntas indagatorias como '¿Qué nos haría sentir seguros de que esto no fallará en producción?' para sacar a la luz expectativas implícitas y convertirlas en criterios explícitos y medibles.

Documentación y Comunicación

¿Qué debe documentarse o compartirse antes de estar terminado?

Usa este tema para sacar a la luz las expectativas de documentación y de compartir conocimiento que mantienen al equipo alineado y reducen la confusión futura. Invita a los participantes a considerar quién necesita conocer el cambio y qué artefactos deberían existir. Esta suele ser la parte más pasada por alto de 'terminado', así que fomenta una reflexión honesta sobre las brechas del pasado.

Pruebas y Validación

¿Cómo verificamos que el trabajo realmente funciona?

Este tema se centra en los pasos de verificación que prueban que el trabajo cumple los requisitos y se comporta como se espera. Guía al equipo a pensar más allá de las pruebas automatizadas para incluir pruebas manuales, exploratorias y de aceptación. Anímalos a definir quién valida el trabajo y en qué entorno.

Despliegue y Preparación

¿Qué debe cumplirse para lanzar el trabajo de forma segura?

Aquí el equipo define qué significa que el trabajo esté listo para lanzarse y estar disponible ante los usuarios. Promueve la discusión sobre el despliegue, la monitorización, los planes de reversión y la preparación operativa. Esto ayuda a los equipos a evitar la brecha común entre 'código completo' y 'entregar valor realmente'.

Cuándo utilizar esta retrospectiva

  • Cuando un nuevo equipo se está formando y necesita establecer estándares de calidad compartidos desde el principio.
  • Cuando el trabajo se reabre con frecuencia o se filtran errores a producción, lo que indica criterios de finalización poco claros.
  • Antes de comenzar un nuevo proyecto o sprint para asegurar que todos estén de acuerdo sobre cómo se ve lo terminado.
  • Al incorporar nuevos miembros que necesitan comprender las expectativas de calidad del equipo.
  • Durante una retrospectiva cuando el equipo identifica inconsistencias en cómo se considera completo el trabajo.

Preguntas sugeridas para romper el hielo

  • Si 'terminado' tuviera personalidad, ¿cómo sería: perfeccionista, pragmático o héroe de último minuto?
  • ¿Cuál es la cosa más sorprendente que descubriste alguna vez que NO estaba realmente terminada?

Ideas y consejos para su reunión retrospectiva

  • Co-crea la Definición de Terminado con todo el equipo para que todos sientan que es suya; evita que una sola persona dicte los estándares.
  • Mantén los criterios realistas y alcanzables; una DoD demasiado ambiciosa que nunca se cumple socava su propósito.
  • Haz que cada criterio sea específico y verificable para que no haya ambigüedad sobre si se ha cumplido.
  • Trata la Definición de Terminado como un documento vivo y revísala periódicamente a medida que evolucionan los estándares y herramientas de tu equipo.
  • Anima a los miembros más callados del equipo a contribuir dándoles tiempo para añadir ideas de forma independiente antes de la discusión grupal.
  • Distingue entre la Definición de Terminado y los criterios de aceptación: la DoD aplica a todo el trabajo, mientras que los criterios de aceptación son específicos de cada historia.

Preguntas frecuentes

¿Qué es una Definición de Terminado en ágil?
Una Definición de Terminado es un conjunto compartido y explícito de criterios que una pieza de trabajo debe cumplir antes de considerarse completa. Crea un estándar de calidad consistente en todo el equipo y reduce la ambigüedad sobre lo que significa 'finalizado'.
¿En qué se diferencia la Definición de Terminado de los criterios de aceptación?
La Definición de Terminado aplica a todos los elementos de trabajo como una lista de verificación de calidad universal, mientras que los criterios de aceptación son específicos de una historia de usuario individual y describen sus requisitos únicos. Ambos deben cumplirse para que el trabajo esté verdaderamente completo.
¿Quién debe participar en la creación de la Definición de Terminado?
Todo el equipo debe colaborar, incluyendo desarrolladores, testers, diseñadores y el product owner. La propiedad compartida asegura que los criterios sean realistas, completos y respetados por todos.
¿Con qué frecuencia debemos actualizar nuestra Definición de Terminado?
Trátala como un documento vivo y revísala periódicamente, por ejemplo durante las retrospectivas o a medida que tus herramientas, habilidades y estándares de calidad maduran. Muchos equipos la revisan cada pocos sprints.
¿Cuánto tiempo toma crear una Definición de Terminado?
Una sesión inicial normalmente toma de 45 a 90 minutos según el tamaño del equipo y cuánta alineación ya exista. Las revisiones posteriores suelen ser mucho más cortas.

¿Es la primera vez que participa en una retrospectiva? Lea nuestra guía sobre cómo llevar a cabo una retrospectiva →