Escribir historias del usuario

Para crear correctamente la lista, el gerente de proyectos debe considerar factores como las descripciones, el valor, el orden y las estimaciones. Esto garantiza que tú, como gerente de proyectos, incluirás suficiente información para cumplir la visión del propietario del producto para el valor del usuario. Ahora que conoces los diversos campos asociados con cada elemento de la lista, analicemos una forma popular de capturar y administrar esos elementos de la lista, las historias de usuario.

Las historias de usuario son descripciones breves y simples de una característica desde la perspectiva del usuario. Esto ayuda al equipo a crear una solución centrada siempre en el usuario y en la experiencia del usuario. Las historias de usuarios pueden comenzar grandes y amplias o pueden resumirse y ser tan breves o específicas como sea posible. 

Las historias de usuario constan de tres elementos diferentes: el usuario, la acción que realizará, y el beneficio para ellos. Estos elementos pueden tener varios formatos diferentes, pero el más común es "Como <user role>, quiero esta <acción> para poder obtener este <valor>". Para escribir historias de usuario efectivas, el equipo debe tener un usuario en mente. Imagina que el usuario interactuará con el producto para lograr un resultado específico. 

Cada historia de usuario debe cumplir seis criterios diferentes, representados por las siglas INVEST, o invertir en inglés. 

I por independent (independiente): la historia debe poder iniciar y terminar por su cuenta. No depende de otra historia para terminar. 

N es por negotiable (negociable): hay espacio para la negociación y el debate sobre este elemento. 

V es de valuable (valioso): esto significa que completar la historia de usuario tiene que aportar valor. 

E es por estimable (estimable): nuestra Definición de Listo debe ser clara para que el equipo pueda asignar una estimación a cada historia de usuario. 

S es por small (pequeño): cada historia de usuario debe entrar en un Sprint planificado. Si la historia de usuario es demasiado grande, se la debe dividir en historias más pequeñas. Las historias con prioridad baja en la lista pueden ser grandes hasta que se convierten en una prioridad para un próximo Sprint. 

T es por testable (comprobable): se puede crear una prueba para comprobar y asegurar el cumplimiento de los criterios de aceptación. 

Mientras que el propietario del producto es el principal responsable de escribir historias de usuario, el equipo tiene la responsabilidad de aportar retroalimentación sobre la historia de usuario para garantizar la claridad y el cumplimiento de los criterios de inversión antes de invertir tiempo en ello. Además de las historias de usuario, necesitas conocer el término epopeya, que simplemente representa un grupo o una colección de historias de usuario. 

Con la historia de usuario, el propietario del producto crea algo llamado criterios de aceptación, que es una lista de verificación que se usa para decidir si la historia de usuario está terminada. Para que la historia de usuario esté terminada, se debe cumplir la lista de verificación de criterios de aceptación. 

Cada historia de usuario en la lista debe escribirse de esta manera. Es natural que los artículos que figuran primero en la lista de prioridades tengan más detalles y menos áreas grises. Al evitar las precisiones en los elementos de baja prioridad, se ahorra al equipo tiempo de trabajo en elementos que pueden terminar perdiendo prioridad más adelante.

Fuente:
Coursera-Gestión de Proyectos de Google.