¿Cómo crear una buena historia de usuario?

La primera pregunta que nos viene a la mente es: ¿Quién debería escribir la historia de usuario? La respuesta es sencilla el Product Owner. ¿Por qué? Porque el es el responsable de todas las tareas que entran en el equipo. El Product Owner debe hacerse no sólo responsable de la priorización de las historias sino que debe conocer en profundidad que tarea se le está pasando al equipo.

Seguidamente vendría otra pregunta: ¿Qué debe contener la historia? La historia de usuario debe contener la explicación de que se desea obtener y para qué. Pero no debe contener como debe hacerse. Es potestad del product owner el decidir que tareas se van a realizar durante un sprint pero también es potestad del equipo el decidir cómo se va a implementar una tarea. Como siempre esto no es una línea pintada en el suelo, el Product Owner y el equipo tienen espacio para hablar sobre las historias y pueden llegar a consensos que no acuerdos (que sería lo más indicado, si todo el mundo comparte la idea y la forma de llevarla a cabo es más fácil avanzar y coger la responsabilidad).

Escribir una historia de usuario no es tan sencillo como coger la típica plantilla "As who, I want what so that why". Requiere algo más que eso !!!!.

Por ejemplo siguiendo esta plantilla podría escribir una historia tal que así:

Como Compañía, quiero que los usuarios de la web pasen más rato en nuestro site porque así tendremos más posibilidades de ingresar dinero por publicidad.

Como historia podría ser una historia válida, no lo niego. Pero si paso esto a uno de mis equipos para que valoren la historia tengo dos opciones: una que den una estimación sobre algo que no se aproxime a lo que el cliente tiene en la cabeza o dos que me tiren la historia a la cabeza y salga en la próxima retrospectiva en el lado negativo de la pizarra (yo me decanto por esta segunda :-) ).

En primer lugar, una historia de usuario debe ser concreta en su explicación, debe expresar de una forma inequivoca la funcionalidad que se desea implementar.

¿Esto implica que escribir como quiero que la implemente? No !!.

¿Esto implica que debo escribir una historia de dos páginas? No !!

En primer lugar el Product Owner debe adaptarse al equipo, a la forma de entender las cosas, a su forma de interactuar, a su lenguaje. Cada equipo es un ecosistema en si mismo independientemente de las normas tanto formales como informales de la compañía en la que estén. Esta sintonía no se genera de la noche a la mañana requiere dar un paso tras otro, por tanto la respuesta a ¿Cómo consigo esto? es: simple prueba y error juntado con una pizca de empatía.

Por tanto, la historia de usuario debe explicar de una forma clara para el equipo de que se desea obtener con ella. Por otro lado debe dejar claro también que criterios se utilizarán para validar que el resultado de dicha historia cumple con los objetivos para los que fue creada. De esta forma el equipo podrá validar que su trabajo se está desarrollando acorde con el plan establecido y evitará sorpresas al final de sprint.