La definición de "terminado" es una declaración explícita y compartida de las condiciones que deben cumplirse para que un trabajo se considere completo. A diferencia de los criterios de aceptación, que son específicos de cada elemento, se aplica de manera uniforme a todo lo que produce un equipo y refleja el estándar de calidad que este se impone.
Su propósito es lograr que la completitud sea objetiva y consistente. Sin ella, "terminado" significa lo que cada desarrollador entienda, lo cual varía según la presión del tiempo y a quién se le pregunte. Para algunos, "terminado" incluye pruebas, documentación, comprobaciones de accesibilidad e implementación; para otros, significa que el código compila en su máquina. Esta variación es invisible hasta que surgen las consecuencias, generalmente como defectos detectados tardíamente o como trabajo que debe revisarse antes de su lanzamiento.
Una definición típica abarca la finalización de la revisión de código, la cobertura de pruebas automatizadas según un estándar acordado, la superación de todas las pruebas, el cumplimiento de los requisitos de accesibilidad, la actualización de la documentación, la consideración de los aspectos de seguridad, el rendimiento dentro de los umbrales definidos y el despliegue en al menos un entorno de preproducción. El contenido específico es menos importante que el hecho de que esté acordado, documentado y aplicado en la práctica, en lugar de ser meras aspiraciones.
La función más importante es evitar la acumulación silenciosa de trabajo oculto. Los elementos marcados como completados sin pruebas, documentación ni correcciones de accesibilidad se presentan como progreso, pero generan obligaciones que deben cumplirse posteriormente, generalmente en peores condiciones. Un equipo que informa de entregas constantes mientras acumula este trabajo pendiente está informando de una ilusión, y la realidad llega meses después con una ralentización inexplicable.
También protege la calidad bajo presión, que es cuando más importa y cuando es más probable que se abandone. Cuando se acerca una fecha límite, la presión para flexibilizar el estándar es intensa y la flexibilización rara vez es explícita; simplemente se marcan las tareas como terminadas omitiendo partes. Considerar la definición como innegociable y, en cambio, reducir el alcance cuando el cronograma está en peligro, es la disciplina que distingue a los equipos cuya velocidad es real de aquellos cuyo progreso declarado es fruto de un esfuerzo futuro.
La definición debe evolucionar a medida que mejoran las capacidades, en lugar de establecerse una sola vez. Un equipo sin despliegue automatizado no puede incluirla inicialmente, pero debería añadirla una vez que disponga de la capacidad necesaria. Revisar la definición periódicamente, normalmente en retrospectivas, y elevar el estándar a medida que las prácticas maduran, la convierte en un mecanismo de mejora continua en lugar de una lista de verificación estática.
La definición también debe ser alcanzable, ya que un estándar que el equipo no pueda cumplir en condiciones normales será ignorado en lugar de renegociado abiertamente, y una definición ignorada es peor que una modesta, porque elimina por completo la referencia compartida. Establecerla al nivel que el equipo pueda mantener de forma genuina y luego elevarla deliberadamente a medida que mejora su capacidad, genera un estándar que realmente rige el comportamiento.
Cuando un trabajo realmente no cumple con el estándar, la respuesta honesta es registrar la excepción explícitamente en lugar de redefinir el concepto de "terminado". Un artículo entregado sin una verificación específica, por una razón justificada, y con el seguimiento de la corrección, es una decisión gestionada. El mismo artículo marcado como completado, pero sin registrar la omisión, constituye una deuda técnica que nadie ha acordado y que nadie recordará.
Dado que la definición determina lo que significa calidad en la práctica, necesita el acuerdo de las personas responsables de las consecuencias, en lugar de solo del equipo de entrega. En la práctica se establece dentro de desarrollo de productos con los estándares de accesibilidad y experiencia extraídos de Auditoría de experiencia de usuario criterios y los umbrales de rendimiento de rendimiento web presupuestos, de modo que la norma refleje la obligación en su totalidad y no solo la funcional.