Publicaciones

El checklist de definicion de hecho que tu equipo realmente necesita

Todo equipo Scrum tiene un momento en el que alguien marca una historia como "hecha" y otra persona pregunta: "pero, escribiste las pruebas?" Esa brecha entre lo que una persona considera terminado y lo que el equipo realmente necesita es exactamente lo que resuelve una Definicion de Hecho. La Guia Scrum de 2020 elevo el DoD de algo opcional a un compromiso formal vinculado al Incremento. Sin embargo, la investigacion del Estudio de Rendimiento de Equipos de Producto de Ron Lichty muestra que solo el 45% de los equipos tienen un DoD creado por su propio equipo. El resto trabaja sin uno o sigue un checklist que alguien mas les entrego. La parte interesante: solo las definiciones de hecho creadas por el equipo se correlacionan con alto rendimiento. Las impuestas externamente no muestran correlacion alguna.

Que es realmente la definicion de hecho

El DoD es un estandar de calidad compartido que se aplica a cada pieza de trabajo que tu equipo entrega. No es lo mismo que los criterios de aceptacion.

	Definicion de Hecho	Criterios de aceptacion
Alcance	Universal, se aplica a todo el trabajo	Especifico de una historia
Enfoque	Estandares de calidad y proceso	Requisitos funcionales
Quien lo escribe	Todo el equipo Scrum	Product Owner (con aportes del equipo)
Ejemplo	"Codigo revisado por al menos un desarrollador"	"El usuario puede filtrar por rango de fechas"

Ambos deben cumplirse antes de que una historia este completa. Los criterios de aceptacion te dicen que construir. El DoD te dice que tan bien debe estar construido.

Un checklist de definicion de hecho en tres niveles

No todos los equipos necesitan el mismo DoD. Una startup lanzando su MVP tiene necesidades de calidad diferentes a las de una plataforma de salud con requisitos de cumplimiento. Aqui hay un enfoque por niveles.

DoD principiante

Para equipos que recien comienzan con una definicion de hecho formal:

DoD intermedio

Para equipos con CI/CD establecido y algunos sprints de experiencia:

DoD avanzado

Para equipos maduros que despliegan a produccion cada sprint: El nivel adecuado depende de tu contexto. Comienza con un checklist que tu equipo pueda cumplir consistentemente, luego sube el estandar con el tiempo. Agregar elementos que tu equipo omite rutinariamente solo entrena a todos a ignorar el DoD por completo.

Por que el DoD importa mas de lo que crees para la estimacion

Aqui es donde la mayoria de los articulos sobre la definicion de hecho se detienen. Pero el vinculo entre el DoD y la precision en las estimaciones es la razon mas subestimada para hacerlo bien. La Guia Scrum lo dice claramente: los desarrolladores pronostican con mas confianza cuando entienden su Definicion de Hecho. Cuando tu equipo estima una historia durante el planning poker, esa estimacion deberia incluir todo lo requerido para cumplir el DoD. No solo escribir el codigo, sino la revision, las pruebas, el despliegue, todo. Los equipos que estiman solo el esfuerzo de codificacion y luego descubren las actividades del DoD al final del sprint se sobrecomprometen consistentemente. El trabajo no tomo mas tiempo del estimado. La estimacion simplemente ignoro la mitad del trabajo. Cuando agregas nuevos elementos a tu DoD (como escaneo de seguridad o pruebas de rendimiento), espera que la velocidad disminuya temporalmente. Eso es saludable. Tu velocidad simplemente se esta volviendo honesta.

Cinco anti-patrones que socavan tu DoD

1. Configurarlo y olvidarlo

El equipo escribio un DoD hace seis meses y no lo ha revisado desde entonces. Las herramientas cambian y el producto crece. Revisa el DoD en tus retrospectivas aunque no lo cambies cada vez.

2. Creado por una sola persona

Un lider tecnico o Scrum Master redacta el DoD solo y lo presenta como definitivo. El resto del equipo nunca siente propiedad sobre el, asi que lo tratan como opcional. La solucion: construirlo juntos en un taller. Todos los que hacen el trabajo deberian opinar sobre lo que significa "hecho".

3. Demasiado vago para verificar

"El codigo es de buena calidad" y "pruebas realizadas" no son verificables. Cada elemento deberia tener una condicion clara de aprobado/reprobado. "El codigo pasa el analisis estatico con cero problemas criticos" es algo que puedes comprobar. "El codigo esta limpio" es cuestion de opinion.

4. Bajar el estandar bajo presion

Cuando los plazos se ajustan, los equipos a veces debilitan el DoD para lanzar mas rapido. La Guia Scrum de 2020 es explicita aqui: el DoD puede evolucionar para mejorar la calidad, pero no deberia debilitarse. Recortar esquinas en calidad no te acelera. Crea la ilusion de velocidad mientras acumula problemas para sprints futuros.

5. Confundir DoD con criterios de aceptacion

El DoD es universal. Los criterios de aceptacion son especificos de cada historia. Mezclarlos significa que pierdes el estandar de calidad o te olvidas de los requisitos funcionales. Mantenlos como checklists separados que funcionan juntos.

Como construir tu primer DoD

Si tu equipo aun no tiene una definicion de hecho, aqui hay una forma practica de crear una. Para un punto de partida rapido, un generador de definition of done puede redactar una lista inicial basada en el contexto de tu equipo.

1. Comienza con lo que ya esta sucediendo

   Pregunta a tu equipo: "Que hacemos ya antes de considerar algo como hecho?" Anota cada respuesta. La mayoria de los equipos ya tienen estandares informales que no han sido documentados.

2. Identifica las brechas

   Observa los bugs recientes o incidentes en produccion. Que los habria detectado antes? Esas brechas se convierten en candidatos para nuevos elementos del DoD.

3. Mantenlo corto

   Apunta a 6-12 elementos. Cada elemento deberia ganarse su lugar previniendo una categoria real de problemas. Si no puedes senalar un problema especifico que un elemento detectaria, eliminalo.

4. Hazlo visible

   Publica el DoD donde el equipo pueda verlo durante la planificacion de sprint y el trabajo diario. Un checklist enterrado en una wiki es un checklist que nadie lee.

5. Revisalo en cada retrospectiva

   Agrega un punto fijo en la agenda de tus retrospectivas. Pregunta: "El DoD detecto lo que necesitaba? Se escapo algo? Deberiamos agregar o eliminar elementos?"

Que hacen diferente los equipos de alto rendimiento

La investigacion de Ron Lichty apunta a un patron claro. Los equipos de alto rendimiento son duenos de su DoD y lo evolucionan deliberadamente. Tambien lo usan para mantener las estimaciones honestas en lugar de optimistas. Estos equipos automatizan la mayor parte del checklist posible. Las verificaciones de cobertura de codigo y el analisis estatico se ejecutan en pipelines de CI/CD junto con escaneos de seguridad. El DoD se hace cumplir por el sistema en lugar de por la memoria, lo que libera al equipo para concentrarse en los elementos que realmente requieren juicio humano, como si los criterios de aceptacion se cumplen desde la perspectiva del usuario. Los equipos mas maduros vinculan su DoD a resultados de negocio, no solo a estandares tecnicos. Martin Hinshelwood da un ejemplo: "En vivo en produccion, recopilando telemetria, apoyando o disminuyendo la hipotesis inicial." Ese es un equipo cuya definicion de hecho no es solo "el codigo funciona" sino "estamos aprendiendo de lo que lanzamos."

Para comenzar

Elige tres elementos del checklist principiante de arriba. Escribelos en una pizarra o ponlos en un documento compartido. Usalos durante un sprint. En la retrospectiva, pregunta que funciono y que falta. Agrega uno o dos elementos. Repite. Un DoD pequeno y consistente que el equipo realmente sigue supera a uno completo que todos ignoran. Construye el habito primero, luego sube el estandar. Y la proxima vez que alguien pregunte si una historia esta hecha, tendras una respuesta que no requiere una conversacion de 10 minutos. Si tu equipo usa planning poker para estimar, manten el DoD visible durante esas sesiones. Es la forma mas rapida de asegurarte de que las estimaciones reflejen el alcance completo de lo que "hecho" realmente significa.