Marcar una Historia de Usuario como DONE

 

¿Qué busco transmitir?

En muchas lecturas encuentras todo tipo de información sobre la definición de Historias de Usuario:

• Las 3 C's: Card, Conversation y Confirmation
• Definición de READY
• Modelo INVEST para ayudar a la descomposición en historias más pequeñas
• Definición de DONE (DoD)
• Specification by example
• ...

En este post, lo que busco no es centrarnos en la definición de DONE, sino en qué opciones tenemos para comprobar que realmente una Historia de Usuario la podemos marcar como DONE.

Algunas referencias antes de meternos en materia

Algunas referencias, independientemente del orden de importancia o que aporten más o menos, serían estas:

• En scrum.org encontramos este artículo: https://www.scrum.org/resources/blog/definicion-de-terminado-done
• En proyectosagiles.org encontramos este artículo: https://proyectosagiles.org/definicion-de-hecho-definition-of-done/ . En él se profundiza mucho más y te da una visión más clara.
• Jerónimo Palacios nos hace también una muy buena introducción a las historias de usuario y sus elementos: https://jeronimopalacios.com/2016/05/los-elementos-una-buena-historia-de-usuario/
•  Javier Garzás ya introducía su importancia en este post: https://www.javiergarzas.com/2014/01/proyecto-agil-terminado-el-done.html y en este otro post: https://www.javiergarzas.com/2018/12/dod-las-pruebas-aceptacion.html en el que diferencia entre DoD, pruebas de aceptación y criterios de aceptación.

Con estos enlaces, navegando un poco más por la red, con algún curso de formación (recuerda que el curso tiene que ser bueno e impartido por gente que sabe de lo que habla, sino, tendrás un problema,pensarás que sabes y eso es peor que saber que no sabes), y finalmente, con el día a día con tu equipo de trabajo, irás adaptando e interiorizando todos estos conceptos.

Sobre los enlaces anteriores, en todos, a menos que se me haya escapado algo, carecen de algo importante, como llevar a la práctica el marcar una Historia de Usuario como DONE.

Mark User History as DONE

Partimos de que ya hemos iniciado el sprint y que el equipo está trabajando en resolver o bien la historia más grande del sprint o bien la historia más prioritaria (según el modo de trabajo del equipo, el cual puede no ser ninguno de los dos anteriores). En el primer modo, nos aseguramos que la historia más grande se acabe y no se quede a medias para el siguiente sprint, en el segundo modo, nos aseguramos que lo que entregamos al finalizar el sprint, es de lo más a menos importante para el PO.

Dejando a un lado la organización anterior,  podemos basarnos en el siguiente tablero de sprint en curso para ver un caso práctico:

Hasta aquí, sin problemas, el día a día en Scrum. Un miembro del equipo ya ha cerrado una de las tareas, y vemos que hay dos tareas en progreso en la historia 1 y 3 pendientes de iniciar su desarrollo para la historia 1 también.

Pasamos ahora al siguiente escenario:

En este escenario, el equipo ya ha completado todas las tareas asociadas a la Historia 1, pero nos falta algo muy importante, marcar como DONE la Historia de Usuario en sí, que es lo que realmente verá el PO en la review.

Para ello, se habrá tenido que definir la DoD sobre la Historia de Usuario que deberemos cumplir para dar el último paso. Pero, ¿quién se hace responsable de este paso? Os paso algunos casos que hemos estado valorando:

1. Para el caso en el que tengáis equipo de mantenimiento rotando con el equipo de proyectos en el que el conocimiento se comparta, el último miembro del equipo de proyectos en completar la última tarea, marcará la Historia de Usuario en Waiting For "equipo de mantenimiento". Se habrá elegido un miembro del equipo de mantenimiento para validar todas las DoD del sprint en curso (en cada sprint cambiaría el miembro) y a la vez preparar la review del cierre del sprint. Con esto conseguimos que el equipo de mantenimiento cuando tenga que formar parte del equipo de proyectos tenga esa base de conocimiento para empezar a trabajar en el proyecto desde el momento 0 y además conseguimos hacer que alguien que no ha participado desde el inicio del sprint y que no esté condicionado con lo que se ha hecho (falsa ceguera), tenga esa visión limpia para poder validar la DoD de la Historia de Usuario.
2. El último miembro del equipo en completar la última tarea de la Historia de Usuario será el encargado de validar que la DoD de ésta cumple con todo lo realizado. Con esto se consigue que el equipo entre en la dinámica de que no solo se trata de resolver las tareas definidas en la Historia de Usuario, sino en comprobar también que lo que se ha hecho cumple con las expectativas definidas en la DoD.
3. Como una tarea más dentro de las responsabilidades del Scrum Master. En este caso se podría ver como un "controller" pero no es el caso. El objetivo que se persigue es el mismo que en el punto 1, alguien que no está condicionado por lo que se ha hecho y tiene conocimiento suficiente de lo que se está pidiendo.

Resumen

1. Se necesita una comunicación eficaz entre todos los involucrados en el proyecto, esto no lo hemos dicho antes, pero es la base sobre la que partir. Sin esta comunicación, se podría tener mucho desperdicio tanto en el proyecto como en el sprint en curso.
2. Se debe interiorizar la calidad como algo innato en el desarrollo del producto. La calidad dependerá tanto del equipo técnico (ya entraremos en lo que es un equipo de alto  rendimiento) como de la DoD, sin ésta puedes creer que has hecho un gran trabajo pero realmente no es así: no te has preocupado por los criterios de aceptación, ha aumentado la deuda técnica, no has hecho el esfuerzo a nivel de BDD de entender los distintos casos de uso, no has integrado todos los cambios en el entorno correspondiente, ... 
3. Además de definir una DoD, que puede que sirva para la mayoría de Historia de Usuario, debes de definir una estrategia para la comprobación de esa DoD. En el blog he puesto 3 casos, pero pueden ser cualesquiera que se te ocurran y que se adapten bien a tu equipo.