¿Cómo medir la calidad de las historias de usuario?

Buenas prácticas con historias de
usuario - gracias Miguel Angel Sobrino

En 2003 Bill Wake desarrolló un método llamado INVEST para asegurar la calidad en la escritura de historias de usuario. El método sirve para comprobar la calidad de una historia de usuario revisando que cumpla una serie de características:

• I - Independent (independiente)
• N - Negotiable (negociable)
• V - Valuable (valiosa)
• E - Estimable (estimable)
• S - Small (pequeña)
• T - Testable (comprobable)

Independent (independiente)

Es ventajoso que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello las historias deberían de ser totalmente independientes (lo cual facilita el trabajo posterior del equipo). Resaltar que las dependencias entre historias de usuario pueden reducirse combinándolas en una o dividiéndolas de manera diferente.

Negotiable (negociable)

Una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados con el cliente o usuario durante la fase de conversación poco antes de su inclusión en un sprint. Por tanto, se debe evitar una historias de usuario con demasiados detalles porque limitarían la conversación acerca de las mismas.

Valuable (valiosa)

Una historia de usuario tiene que ser valiosa para el cliente o el usuario, ha de tener valor de negocio. Una manera de hacer una historia valiosa es que la escriba el mismo.

Estimable (estimable)

Una buena historia de usuario debe de poder ser estimada con la precisión suficiente para ayudar al cliente, usuario o Propietario del Producto a priorizarla en la pila de producto. La estimación la realizará el equipo de desarrollo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento serán necesarias mas fases de conversación acerca de la misma).

Small (pequeña)

Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario facilitando así su estimación.

Testable (comprobable)

La historia de usuario debería de ser probada (fase confirmación de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

Consejos para unas buenas prácticas:

• Siempre escribir las historias con el "qué", evitar el "cómo".
• No escribir una descripción exhaustiva, solo lo justo.
• Escribir criterios de aceptación y ser suficientemente explícito.
• Estimar todas las historias, no hacerlo puede crear falsas expectativas.
• No fiar toda la información en las tarjetas o post-its, a veces es buena idea una documentación externa como una wiki por ejemplo.
• Nunca dar una historia por finalizada cuando está "prácticamente hecha", siempre en base a la definición de hecho (DoD) y a los criterios de aceptación.

Tarjetas para historias de usuario de Braintrust preparadas para INVEST