Este concepto es especial, porque es uno de esos que muchos hablan, pero pocos pueden explicar bien. Espero ser de los segundos…

Una historia de usuario es la menor definición responsable de una funcionalidad a desarrollar. Es tan mínima que es solo un poco más que un título y una descripción.

No parece nada útil, de que puede servir algo tan mínimo… Bueno, la belleza es que, lo poco que se escribe, resulta ser suficiente para la primera etapa de vaciar, ordenar y discutir las funcionalidades cuando el proyecto inicia o cuando el cliente llega con nuevas ideas.

Pero hay un método para la locura.  Hay tres piezas de información en una historia de usuario que conforman este conjunto mínimo de datos: protopersona “dueña”,  comportamiento esperado del sistema y finalmente, problema de negocio.

La protopersona es un perfil de usuario específico, definido de acuerdo a comportamientos y características comunes que hagan sentido a la aplicación en desarrollo. Generalmente se les coloca un nombre común y se les hace un pequeño perfil biográfico. Esto nos facilita colocarnos en los zapatos de un usuario. Quizás en otro post hablaré más sobre las protopersonas si les interesa  (hay comentarios abajo, ahí me pueden alentar! ).

El comportamiento lo que desearía esa protopersona que el sistema le permitiera hacer. Ojo, es un “Qué” y no un “Cómo”. No debiera decir “necesito que envíe un correo…” sino “me gustaría recibir una notificación”. Esas sutiles diferencias importan mucho, ya que una descripción mal hecha puede predisponer a un programador o diseñador a elegir un método por sobre otro. Dejar las opciones de implementación abiertas permite enfocar a equipo en buscar el match correcto para el problema a la mano.

La pieza final es el problema de negocios, que no es nada más que una justificación de la necesidad. Es el “Porqué” y debiera estar redactado como si fuera una meta a lograr.

Por ejemplo, digamos que Alberto es una protopersona para un sistema e-commerce y representa a un visitante promedio.  La historia para el carro de compras sería:

Como Alberto

Me gustaría poder ir recolectando productos que me interesen a medida que reviso el sitio

Para de esta forma, poder revisar al final y pagarlos de una sola vez.

Como dije en un principio, es lo mínimo que responsablemente se puede escribir sobre una funcionalidad,  pero esto se puede ampliar luego con  escenarios, que definen condicionales y casos de borde. Un ejemplo:

Estando en el listado de productos que me han interesado

Cuando presiono el botón modificar

Entonces se activa la opción de eliminar los productos que considere que ya no son relevantes

Y también se activa la opción de agregar más unidades de cada producto.

Esos escenarios también tienen partes importantes: estado inicial, pre condiciones y resultado esperado. Estos escenarios luego se pueden convertir en pruebas de aceptación, siempre y cuando las pre condiciones sean claras y determinantes y los resultados esperados sean medibles.

La sintaxis de estas historias de usuario no es algo terriblemente importante, pero ayuda tener un esquema para guiarse. También cuando se realizan automatizaciones de pruebas de aceptación, las herramientas generalmente están definidas para entender cierto tipo de estructura, la más común es llamada Gherkin y si vas a realizar automatizaciones vale la pena utilizarla, pero sino, propongo una estructura similar pero más “en español”:

Como

Me gustaría

Para de esta forma

y en los escenarios:

Estando en

Y 

Cuando 

y luego 

Entonces 

y También 

Las historias de usuario las puedes escribir en tarjetas, en documentos electrónicos, en una wiki o en tu sistema de gestión de proyecto, lo importante es que sea legible, accesible por todos en el equipo y que le realices seguimiento, ya que cuando realizamos mayor análisis y generamos documentación adicional, esta debe hacer referencia a las historias y escenarios que les dan motivo de existencia. Además, al backlog probablemente no entrarán historias de usuario completas, sino que se hará una división un poco más granular en tareas y esas también deben hacer referencia a la historia de origen para siempre tener el contexto adecuado.

Bueno, eso por hoy, si les quedaron dudas o tienen aportes, por favor, los invito a escribir en los comentarios 🙂