Criterios de calidad

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

Todo el código ha sido revisado y aprobado por al menos otro desarrollador.
La cobertura de pruebas unitarias alcanza el umbral acordado del 80 % o más.
No quedan abiertos errores críticos ni de gravedad alta.
Documentación y comunicación

¿Qué hay que documentar o compartir antes de terminar?

La documentación para usuarios 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 los endpoints nuevos o modificados.
Pruebas y validación

¿Cómo comprobamos 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.
El product owner ha validado la funcionalidad antes de cerrarla.
Despliegue y preparación

¿Qué debe cumplirse para lanzar el trabajo con seguridad?

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.
Hay un plan de reversión o recuperación por si algo sale mal.

¿Qué es la Definición de Terminado?

¿Alguna vez entregaste algo y luego descubriste que no estaba realmente terminado? Una Definición de Terminado (DoD, por sus siglas en inglés) es la lista compartida de criterios que todo trabajo debe cumplir antes de que alguien lo dé por completado. Se aplica a cada historia de usuario, funcionalidad e incremento, así que "terminado" significa lo mismo sin importar quién haya hecho el trabajo. En Scrum, la Definición de Terminado marca el nivel de calidad de cada incremento. Ponerla por escrito acaba con los debates de "¿esto está terminado?" en la revisión y evita que el trabajo oculto, como pruebas o documentación pendientes, se arrastre al siguiente sprint. Esta sesión reúne a desarrolladores, testers, diseñadores y product owners para construir la lista juntos, de modo que incluya los pasos que cada uno sabe que suelen saltarse. El tablero tiene cuatro columnas: Criterios de calidad, Documentación y comunicación, Pruebas y validación, y Despliegue y preparación. Todos añaden criterios y luego el equipo los agrupa y vota para acordar la lista. Trata el resultado como un documento vivo y revísalo a medida que cambien tus herramientas y estándares. Para más contexto, consulta la guía de Scrum.org sobre la Definición de Terminado.

Formato de colaboración Definición de Terminado

Criterios de calidad

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

Enumerad las comprobaciones técnicas y de calidad que todo trabajo debe superar, como la revisión de código, la cobertura de pruebas, el rendimiento y los estándares de programación. Pregunta "¿Qué nos daría la confianza de que esto no fallará en producción?" para sacar a la luz las expectativas no escritas y hacerlas medibles.

Documentación y comunicación

¿Qué hay que documentar o compartir antes de terminar?

Cubrid lo que hay que dejar por escrito, o comunicar a otras personas, antes de que el trabajo cuente como terminado. Pregunta quién necesita conocer un cambio y qué debería existir después. Los equipos suelen saltarse esta parte, así que pregunta por carencias anteriores.

Pruebas y validación

¿Cómo comprobamos que el trabajo realmente funciona?

Acordad las comprobaciones que demuestran que el trabajo hace lo que debe. Id más allá de las pruebas automatizadas e incluid pruebas manuales, exploratorias y de aceptación, y decidid quién da el visto bueno y en qué entorno.

Despliegue y preparación

¿Qué debe cumplirse para lanzar el trabajo con seguridad?

Definid qué tiene que cumplirse antes de que el trabajo salga a producción. Hablad del despliegue, la monitorización, los planes de reversión y quién dará soporte una vez publicado. Así se cierra la brecha entre un código terminado y una funcionalidad que la gente puede usar de verdad.

Cuándo utilizar este estudio retrospectivo

  • Cuando se forma un equipo nuevo que necesita acordar estándares de calidad desde el principio.
  • Cuando el trabajo se reabre una y otra vez o llegan errores a producción, lo que suele indicar que no hay acuerdo sobre qué significa terminado.
  • Antes de empezar un proyecto nuevo, para que el equipo acuerde el nivel exigido antes de comenzar el trabajo.
  • Al incorporar a nuevos miembros que necesitan conocer las expectativas de calidad del equipo.
  • Cuando una retrospectiva revela que las personas del equipo entienden de forma distinta qué es completar algo.

Preguntas sugeridas para romper el hielo

  • Si "terminado" tuviera personalidad, ¿cómo sería: perfeccionista, pragmático o héroe de última hora?
  • ¿Qué es lo más sorprendente que descubriste una vez que en realidad no estaba terminado?

¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →

Ideas y consejos para su reunión retrospectiva

  • Construid la Definición de Terminado con todo el equipo para que todos la sientan suya. No dejéis que la redacte una sola persona.
  • Mantened criterios realistas. Una DoD que el equipo nunca cumple acaba ignorándose.
  • Haced que cada criterio sea lo bastante concreto para poder comprobarlo, así no habrá discusiones sobre si se ha cumplido.
  • Revisadla cada pocos sprints, a medida que cambien vuestros estándares y herramientas.
  • Dad a todos tiempo para añadir ideas por su cuenta antes del debate en grupo, para que las personas más calladas también contribuyan.
  • Mantenedla separada de los criterios de aceptación. La DoD se aplica a todo el trabajo, mientras que los criterios de aceptación pertenecen a una sola historia.

Preguntas frecuentes

¿Qué es una Definición de Terminado en agile?
Es una lista compartida de criterios que todo trabajo debe cumplir antes de que el equipo lo dé por completado. Da a todos el mismo nivel de calidad y pone fin a las discusiones sobre qué significa terminado.
¿En qué se diferencia la Definición de Terminado de los criterios de aceptación?
La Definición de Terminado se aplica a todos los elementos de trabajo. Los criterios de aceptación pertenecen a una historia de usuario concreta y describen lo que esa historia debe hacer. El trabajo solo está completo cuando cumple ambos.
¿Quién debería participar en la creación de la Definición de Terminado?
Todo el equipo, incluidos desarrolladores, testers, diseñadores y el product owner. Las personas siguen un estándar que han ayudado a redactar, y cada rol sabe qué suele pasarse por alto en su área.
¿Con qué frecuencia deberíamos actualizar nuestra Definición de Terminado?
Revisadla cada pocos sprints, a menudo en una retrospectiva, o cuando cambien vuestras herramientas o habilidades. Añadid criterios a medida que el equipo sea capaz de cumplirlos.
¿Cuánto se tarda en crear una Definición de Terminado?
Una primera sesión suele durar entre 45 y 90 minutos, según el tamaño del equipo y el grado de acuerdo que ya exista. Las revisiones posteriores son mucho más breves.
¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión en directo retrospectiva