Qué tengo que documentar en SCRUM? Nada? Se me va a olvidar el porqué tomé esta decisión y no otra… Esta es mi conversación mental cada vez que me enfrento al asunto de la documentación en SCRUM y creo que ha llegado el momento de poner ciertas pautas.

Siempre teniendo claros los principios en los que se basa SCRUM:

  • Compromiso
  • Coraje
  • Enfoque
  • Transparencia
  • Respeto

y el Manifiesto Ágil:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

Uno que quiera cambiar empieza a confundir términos.

Cuánto se documenta en SCRUM?

Pues se documenta lo justo, que no es poco. Si piensas que el documentar se va a acabar con SCRUM, tienes una idea muy equivocada.

Mínimo deberás documentar las Historias de Usuario y los Criterios de Aceptación. La Historias de Usuario son relativamente sencillas de documentar, pero los Criterios de Aceptación… Se supone que alguien no técnico debería de tener manera de comprobar que lo que dice la Historia de Usuario es correcto, y he aquí muchas líneas por escribir. Mejor con un ejemplo:

Documentación en SCRUM

Esto supone que debería de dibujar en una pantalla, una tabla que me saque datos de pedidos. Ahora empecemos a concretar qué significa eso… Si no tengo pedidos me aparece una tabla vacía? Qué estados tiene un pedido? Puede haber un pedido sin estado? Requiere paginar la tabla? qué campos se han de ver? Si he hecho pedido en nombre de otro usuario, también los veo en esta tabla?

Existe un lenguaje denominado Gherkin que permite incluso automatizar los Criterios de Aceptación mediante la frase GIVEN-WHEN-THEN.

Si esto no te parece mucho por escribir, también recuerda que deberías de tener al menos algún repositorio como para saber la arquitectura y dónde poder acceder a la aplicación.

Si vienes del modelo METRICA3

Modelo METRICA3 o situación de gran cantidad de documentación utilizada como instrumento de comunicación entre entidades (departamentos o empresas) vas a identificar que cada tarea genera un artefacto, que no es mas que un documento.

Por lo que podríamos encontrarnos con gran cantidad de texto escrito donde se detalla en exceso la aplicación que se vaya a crear, su contexto y sus detalles. Estos documentos además se suelen duplicar y mantener con versiones para saber cuando dije qué y quién es el culpable de no haber llegado a buen puerto.

También solemos tener gran cantidad de actas de reuniones que nadie suele querer escribir, así como documentos de diseño que se hacen al final para tener un resumen de todo lo acontecido.

Pues la norma es sencilla, quédate con lo estrictamente necesario. Aquellos documentos que necesites para asegurar que la aplicación que estas creando se haga bien.