La definición de «terminado» consiste en una lista de comprobación única para todo el equipo: el estándar que cada historia debe cumplir antes de que se considere completada. Los criterios de aceptación son específicos de cada historia; la definición de «terminado» es global. Al confundir ambos conceptos, «terminado» acaba significando, sin que nos demos cuenta, «funciona en mi equipo».

Todos los equipos han experimentado la diferencia entre «el desarrollador dice que está terminado» y «realmente está listo para su lanzamiento». La definición de «terminado» acorta esa distancia. Se acuerda una vez y se aplica en cada sprint, independientemente de lo que implique cada historia en concreto. Sin ella, «terminado» es una opinión personal, y la diferencia sale a la luz en la demostración o, lo que es peor, en producción.

Lista de comprobación de la «definición de «hecho»» (ejemplo)

Un punto de partida viable para un equipo que se dedica al desarrollo de una aplicación web:

  • Se han cumplido y verificado los criterios de aceptación.
  • Se ha revisado el código y se ha fusionado con la rama principal.
  • Se han escrito pruebas automatizadas que se han superado; no hay nuevas pruebas inestables.
  • No se conocen regresiones ni errores críticos pendientes relacionados con esta tarea.
  • Se han actualizado la documentación y el registro de cambios en los casos en que el cambio afecta a los usuarios.
  • Se ha implementado en el entorno de prueba y se han realizado pruebas de verificación.
  • El responsable del producto lo ha aceptado.

Adopte esta definición y, a continuación, adáptela a lo que su equipo vaya a aplicar realmente. Una definición de «terminado» con un criterio que nadie comprueba es peor que una breve: enseña al equipo a considerar toda la lista como algo meramente decorativo. Asegúrese de que quepa en una sola pantalla y de que cada punto sea verificable.

Definición de «terminado» frente a criterios de aceptación

Esta es la distinción con la que los equipos suelen tropezar con mayor frecuencia. Los criterios de aceptación para una historia de inicio de sesión son específicos de dicho proceso: las credenciales correctas le llevan al panel de control, mientras que tres intentos fallidos bloquean la cuenta. La definición de «terminado» —revisado, probado, implementado— es idéntica para la historia de inicio de sesión, la historia de búsqueda y la historia de facturación. Los criterios son locales y responden a la pregunta «¿hemos creado lo correcto?». La definición de «terminado» es global y responde a la pregunta «¿alguna parte de nuestro trabajo está lista para su entrega?». Una historia no se da por terminada hasta que supera ambas etapas.

Definición de «listo» frente a definición de «terminado»

Son como dos extremos de una estantería, no gemelos simétricos. La definición de «listo» permite que una historia entre en el sprint —lo suficientemente pequeña, clara y estimada—. La definición de «terminado» permite que el trabajo finalizado salga del sprint. «Listo» se refiere a la historia; «terminado», al trabajo. Los equipos que solo cuentan con una de ellas suelen centrarse en «listo» (porque las historias que no están listas llaman mucho la atención) y dejan que «terminado» pase desapercibido —y así es como se acumulan las historias pendientes y las que están «al 90 % completas».

Las tres listas de comprobación dejan de confundirse entre sí en cuanto se comprenda qué es lo que controla cada una de ellas:

Definición de «listo»Criterios de aceptaciónDefinición de «hecho»
Ámbito de aplicaciónGlobal: cada historiaLocal — esta noticiaGlobal: cada historia
GatesInicio del sprintEl desenlace de la propia historiaSalida del sprint
Respuestas«¿Podemos empezar ya?»«¿Hemos creado lo adecuado?»«¿Se puede enviar?»
Propiedad deEl equipo, junto con el responsable del productoResponsable de producto, junto con el equipoEl equipo

¿A quién corresponde definir qué se considera «terminado»?

El equipo lo redacta; el equipo se encarga de su cumplimiento. El scrum master actúa como facilitador y el product owner aporta su opinión sobre el umbral de aceptación, pero son los ingenieros quienes deciden qué implica técnicamente que algo esté «terminado», ya que un concepto de «terminado» mal definido supone una deuda que ellos deben saldar, no la dirección. Vuelva a analizarlo en una retrospectiva cuando la misma laguna siga apareciendo; esa es la señal de que falta algún elemento.

¿Qué es lo que falla?

La «definición de «hecho»» se convierte en un cartel. Se cuelga en la wiki del equipo, se recita durante la formación inicial y se ignora ante la presión de los plazos: «escribiremos las pruebas en el próximo sprint». Dos sprints más tarde, la deuda de pruebas es estructural y la definición se ha convertido en una ficción. Cuando el concepto de «terminado» es impreciso, la velocidad se infla: el equipo acumula puntos por un trabajo que en realidad no está listo para su entrega, y la previsión deja de tener sentido sin que nadie se dé cuenta.

La solución no consiste en una lista más larga, sino en una más corta en la que el equipo se mantenga firme. Una definición de «terminado» solo es real en la medida en que haya una tarea que esté dispuesto a no marcar como terminada porque no cumple con uno de sus criterios.

Los criterios de aceptación determinan el avance de la historia. La definición de «terminado» determina el avance del equipo. Procure que sean lo suficientemente concisos como para que realmente pueda hacerlos cumplir; un criterio que no se hace cumplir no es más que papeleo.

Preguntas frecuentes

¿Cuál es la definición de «terminado» en el método ágil?

La definición de «terminado» consiste en una única lista de comprobación que cada historia debe cumplir antes de que se considere completa; por lo general, debe haber sido sometida a pruebas, revisada, fusionada, documentada e implementada en el entorno de prueba. Se trata de un estándar común para todo el equipo, no de una lista específica para cada historia, y su finalidad es garantizar que «terminado» signifique lo mismo cada vez que alguien lo mencione.

¿Cuál es la diferencia entre la definición de «terminado» y los criterios de aceptación?

La definición de «terminado» es global: el mismo criterio de aceptación para todas las historias. Los criterios de aceptación son locales, es decir, específicos de cada historia. Los criterios de aceptación indican lo que debe hacer esta funcionalidad; la definición de «terminado» indica qué significa «listo para su entrega» en relación con cualquier trabajo que el equipo produzca. Una historia debe cumplir ambos requisitos.

¿En qué consiste una lista de verificación de «definición de finalización»?

Una lista breve y clara de los requisitos que deben cumplirse en cada historia: código revisado e integrado, pruebas escritas y superadas, sin regresiones conocidas, documentación actualizada, implementado en un entorno de pruebas y aceptado por el responsable de producto. Los puntos concretos pueden variar según el equipo, pero la lista debe caber en una sola pantalla y cada línea debe poder verificarse.

¿Cuál es la diferencia entre la definición de «listo» y la definición de «terminado»?

La definición de «listo» marca el inicio del sprint: es el umbral que debe superar una historia antes de que el equipo se comprometa con ella. La definición de «terminado» marca el final del sprint: es el umbral que debe superar el trabajo finalizado antes de su entrega. «Listo» se refiere a que la historia esté bien definida; «terminado» se refiere a que el trabajo esté listo para su entrega.

¿Quién establece la definición de «terminado»?

El equipo de desarrollo es el responsable, normalmente con la ayuda del scrum master. El product owner aporta su opinión sobre los criterios de aceptación, pero son las personas que realizan el trabajo quienes deciden qué implica técnicamente que algo esté «terminado», ya que son ellas quienes pagan las consecuencias cuando dicho concepto se define de forma imprecisa.

Lecturas relacionadas