Definición de Terminado

La Definición de Terminado o
DoD (Definition of Done) es un
acuerdo co-creado por un
equipo, que se aplica a todos los
ítems sobre los cuales trabaja
este equipo.

Incluye un conjunto mínimo de

actividades o condiciones a
cumplir para alcanzar el nivel de
compleción y calidad acordado
en cada ítem de trabajo.

Es un compromiso de todo el
equipo que se puede
incrementar con el tiempo.
 ¿Qué es DoD Kards?

DoD Kards es un juego de cartas cuyo objetivo es

reflexionar y consensuar entre todos los miembros
de un equipo cuáles son los criterios a incluir en su
definición de terminado (DoD).

El alcance del juego es la DoD en el contexto del

desarrollo de software, aplicado a los Items de un
Backlog de Producto (PBI, que muchas veces se
expresan como Historias de Usuario), aunque se
puede extrapolar a otros contextos.

Se recomiendo jugarlo periódicamente (cada 2 a 3

meses), para poder incrementar la DoD del equipo
en forma sostenible.

Para darnos feedback puedes usar el hashtag en

Twitter: #DodKards

DoD Kards es una creación de Kleer, por Camilo Velasquez y

Thomas Wallet, inspirada de Definition of Done Exercise de
David A. Koontz, y se distribuye bajo la licencia Creative
Commons Attribution-ShareAlike 3.0 Unported.
 ¿Cómo jugar?
1. Ubicar las cartas “Ya”, “Más adelante” y “No” en fila
en la mesa o pared.
2. Mezclar todas las cartas de criterios (azul, negro,
verde, rosa) y ubicarlas en una pila boca abajo al
alcance de todos.
3. Dejar en otra pila separada las cartas amarillas
vacías de criterio.
4. De a uno, cada jugador:
a. Roba la siguiente carta de la pila de criterios y
la lee en voz alta.
b. Ubica la carta en la columna que considera
más adecuada (“Ya”, “Más adelante” o “No”).
c. Si alguien no coincide con esta elección, se
conversa durante un tiempo pre-acordado
para lograr un consenso. Si no hay consenso
al finalizar este tiempo, ubicar la carta en la
columna “No”.
5. Se repite el paso 4 hasta que no haya más cartas de
criterios disponibles o cuando lo decida el equipo.
6. En cualquier momento un jugador puede escribir un
nuevo criterio personalizado en una carta amarilla
vacía y usarla en su turno.
 ¡ YA !
A partir de ahora, el
equipo se compromete
a considerar un ítem de
trabajo “Terminado”
solamente si cumple
con cada uno de estos
criterios.

Acciones Hacer visible estos

Sugeridas criterios
Chequear su
cumplimiento entre
todos al terminar un ítem
de trabajo
 Más
adelante...
El equipo no se puede
comprometer con estos
criterios por el momento,
pero coincide que podrían
considerarse en el futuro.

Acciones Revisar estos criterios

Sugeridas nuevamente en unos
meses

Planificar eventuales
acciones para avanzar
hacia la inclusión de
algunos de estos
criterios
 No
Estos criterios no están
claros para el equipo o
no aplican; el equipo no
ve estos criterios como
parte de su DoD, ni ahora,
ni más adelante; o no
hubo consenso del
equipo sobre estos
criterios.

Acciones Investigar luego para

Sugeridas entender mejor algunos
de estos criterios

Volver a conversar luego

los criterios sin
consenso
 Revisión

Todo el código
involucrado fue
revisado en pares
via Code review o pair
programming
 Revisión

Se preparó la
demostración
correspondiente
Incluyendo datos a utilizar,
guión y pasos a seguir.
 Revisión

Se hizo una
pre-demostración

Entre los miembros del

equipo para ensayar y refinar
la demostración real
 Revisión

No se incrementa la
deuda técnica (sin
justificación)
El equipo concuerda en que el
ítem entregado no introduce
nueva deuda técnica, o que se
introduce a conciencia deuda
técnica con una adecuada
justificación.
 Revisión

El product Owner ha
visto una
demostración
de la historia de usuario y la
ha aceptado
 Calidad

Se ejecutaron las
pruebas necesarias
y no quedó ningún incidente
mayor sin resolver
 Calidad

El ítem tiene pruebas

automatizadas

Y todas fueron ejecutadas

exitosamente
 Calidad

El ítem cuenta con

pruebas unitarias
Superando el ___% de code
coverage
 Calidad

El ítem fue verificado

por el servidor de
Integración Continua
Sin levantar ningún incidente
 Calidad

Se cumple con los

estándares de código

… que aplican al caso,

eventualmente a través de
chequeos automáticos de
cumplimiento
 Entornos

El código generado es
almacenado en el
repositorio de
versionamiento
con los commits, tags y/o
comentarios adecuados.
 Entornos

Se ejecutó el build en
el ambiente de
prueba
… sin errores y quedó
disponible para pruebas en el
ambiente.
 Entornos

Se ejecutó el build en
el ambiente _____

… sin errores y quedó

disponible para ejecución en
el ambiente.
 Entornos

Se ejecutó el build en
el ambiente
productivo
… sin errores y quedó
disponible para ejecución en
el ambiente.
 Entornos

El ambiente de
entrega fue
preparado
adecuadamente
Según el caso, el ambiente de
prueba, stage o producción
fue instalado y configurado
adecuadamente.
 Difusión

Se generó o actualizó
la documentación
relevante
Por ejemplo: definición de
API, manual de usuario,
decisiones de diseño
importantes, release notes.
 Difusión

Se notificaron las
personas y/o sectores
involucrados
que necesitan saber de la
resolución del ítem
correspondiente.
 Difusión

Se actualizaron los
radiadores de
información
correspondientes
Por ejemplo: herramientas de
gestión involucradas (Trello,
Jira, etc.), tablero físico de
tareas.
 Difusión

Se capacitaron a los
usuarios involucrados

Para que puedan utilizar

adecuadamente el software
entregado.
 Difusión

Se comunicó al resto
del equipo la
información
relevante
Como por ejemplo la
explicación funcional del ítem
entregado, algunas
consideraciones tecnicas
importante, etc.
DoD Kards