¿Qué es una historia de usuario? Cómo (y por qué) escribir una
Las Historias de Usuario son una herramienta central en la colaboración de los equipos ágiles. Su campo de aplicación es muy amplio y va desde la satisfacción de las necesidades específicas de los clientes hasta el apoyo a los equipos Scrum.
Pero, ¿qué es exactamente una Historia de Usuario y cómo se realiza? En este artículo arrojaremos luz sobre este concepto: le mostraremos cómo debe estructurarse una historia de usuario y cómo trabajar con éxito con esta herramienta.
Descubrir las historias de usuario
Historia de usuario: definición
UserStory es un término inglés que puede traducirse literalmente como " historia de usuario". En el ámbito de la gestión ágil de proyectos y el desarrollo de software, la historia de usuario es una herramienta para describir la funcionalidad de un sistema determinado desde la perspectiva de la experiencia del usuario.
¿Para qué sirve?
La función de la historia de usuario es satisfacer las necesidades y expectativas específicas de los usuarios en relación con determinadas funcionalidades de un software o solución propuestos.
El objetivo de la historia de usuario es hacer comprender al lector las ventajas del sistema en cuestión. De este modo, se puede lograr un mayor grado de concienciación sobre las ventajas del producto o servicio presentado.
Por tanto, una historia de usuario sirve, en última instancia, para aumentar la comprensión de un sistema y, así, potenciar su grado de éxito entre los usuarios.
Historia de Usuario vs. Caso de Uso
El Caso de Uso, o caso de uso, puede considerarse como una versión más masiva de la Historia de Usuario. De hecho, es muy elaborado y detallado, cubre un contexto más amplio y es, por lo tanto, más completo que una Historia de Usuario. Por lo general, incluso comprende varias Historias de Usuario.
El caso de uso es normalmente más duradero que una Historia de Usuario. De hecho, se suele mantener durante todo el desarrollo del sistema, mientras que la Historia de Usuario desaparece tras su finalización en un Sprint.
Escribir una Historia de Usuario
¿Quién la escribe?
Las Historias de Usuario pueden ser escritas por o para los usuarios.
¿Cómo se escribe?
Normalmente la Historia de Usuario es escrita por un equipo, que se dedica a escribirla y optimizarla. Normalmente, el equipo se centra, en primer lugar, en desarrollar ciertos criterios en torno a los cuales desarrollar su historia. Estos pueden ser, por ejemplo, el grado de complejidad, el modelo a seguir, la disposición de la información, etc.
Por tanto, desde el principio hay que definir las propiedades estructurales que se desea atribuir a la historia. Si se trabaja en equipo, hay que dividir las tareas dentro del grupo y fijar el plazo en el que debe realizarse el trabajo.
Para empezar, deben establecerse los Story Points, es decir, números arbitrarios que sirven para estimar cuánto trabajo es capaz de realizar el equipo en cada iteración.
A continuación, también deben fijarse los Sprints, es decir, los ciclos de trabajo que duran de una a cuatro semanas. El conjunto de Story Points y Sprints constituye la base de la Planificación de Historias de Usuario.
☝ En este contexto, se ha hecho referencia a los Sprints en plural. Sin embargo, debe tenerse en cuenta que a menudo sólo es necesaria una iteración o Sprint para la realización de una Historia de Usuario.
El siguiente paso consiste en garantizar que las tareas se expresen claramente y se asignen a los distintos miembros del equipo. La organización y la coordinación son, de hecho, cruciales para escribir una Historia de Usuario de calidad.
Sin embargo, ocurre que las Historias de Usuario se escriben sin un análisis detallado de las tareas. El grado de estructuración de la historia es, de hecho, un factor arbitrario y sujeto a la libre elección del equipo. Evidentemente, cuanto más aspire un equipo a garantizar servicios excelentes, más favorecerá la planificación articulada de la Historia de Usuario.
☝ El objetivo de la planificación de la Historia de Usuario debe ser el beneficio del usuario, no la promoción de la solución, producto o servicio considerado.
¿Cómo proceder?
Las historias de usuario se gestionan en el Backlog. Aquí es donde entra en juego el concepto DEEP, desarrollado por Roman Pichler. Pichler ideó este modelo para gestionar correctamente el Backlog. DEEP es un acrónimo de las siguientes palabras
- Detallado Apropiadamente: las historias de usuario de alta prioridad deben formularse con más detalle que las de baja prioridad.
- Estimada : los componentes de las historias de usuario deben estimarse, especialmente en relación con los puntos de historia. Conocer, aunque sólo sea de forma aproximada, los elementos constitutivos de una historia ayuda a priorizar y seguir el proyecto de lanzamiento.
- Emergente : la Historia de Usuario tiene un carácter dinámico. De hecho, evoluciona y su contenido puede cambiar con frecuencia. Pueden surgir nuevos elementos en función de las valoraciones y comentarios de los lectores. Sobre esta base, las historias de usuario deben modificarse, actualizarse y optimizarse.
- Prioridad : los componentes de la historia o las propias historias con una prioridad alta deben implementarse en primer lugar.
¿Qué enfoque debe darse a una historia de usuario?
Cuando se está en el proceso de escribir una historia de usuario, es bueno tener en mente una estructura básica recomendada :
Como x (papel del escritor), me gustaría xy (referencia a la funcionalidad deseada), con el fin de yy (propósito).
Además de este modelo básico, existen otras alternativas. Otro modelo posible para una historia de usuario es, por ejemplo
Con el fin de yy (propósito), puesto que soy x (rol), me gustaría xy (funcionalidad).
☝ El rol debe coincidir con sus Personas. Una Persona es un representante típico de su grupo objetivo.
Las historias de usuario, como todas las historias, pueden variar en el grado de detalle proporcionado. De hecho, algunas historias pueden limitarse a proporcionar un contenido muy aproximado. Otras, en cambio, pueden presentar un comienzo genérico, para refinarlo más adelante. Otras pueden ser detalladas desde el principio.
Seguir una plantilla para formular una historia de usuario no es obligatorio, pero sí práctico. La experiencia en el campo de las historias de usuario ha demostrado que atenerse a la estructura básica recomendada no sólo ayuda a la formulación, sino que también facilita la comprensión del lector.
¿En qué idioma debe escribirse?
El idioma preferido para redactar una historia de usuario es el inglés. Puede resultar una elección extraña, sobre todo si se trabaja en el ámbito italiano. Sin embargo, hace tiempo que el inglés se ha convertido en la lengua franca en casi todos los países y actualmente se habla a nivel internacional.
Además, este idioma permite un alto grado de concisión, ya que es extremadamente conciso y directo.
Por eso puede ser una elección sensata presentar la historia de usuario en inglés.
Ejemplos de historias de usuario
A continuación se presentan algunos ejemplos de aplicación de los modelos de historias de usuario propuestos.
1. Como amante de las novelas históricas, me gustaría estar informado sobre la salida de libros relevantes, para poder pedirlos a tiempo en la librería.
2. Como amante de las películas de aventuras, me gustaría saber qué películas de este género se han estrenado en su cine, para poder comprar las entradas online.
3. Como amante del cine, me gustaría saber qué promociones hay en su cine para poder encontrar un abono asequible.
Consejos para una Historia de Usuario de calidad
Dado que la historia de usuario pretende ser recibida y comprendida en el menor tiempo posible, es importante que
- Esté escrita utilizando frases cortas e incisivas;
- Contenga un vocabulario sencillo y no rebuscado;
- Evite tecnicismos: las personas sin formación especializada deben ser capaces de entender lo que leen;
- Se centra en dar respuestas directas a las preguntas: ¿quién quiere qué del sistema? ¿Por qué el usuario utiliza el sistema (en qué le beneficia)?
En palabras de Mike Cohn, uno de los principales contribuyentes a la invención de la metodología de desarrollo de software Scrum, todas las historias de usuario ágiles incluyen sólo una o dos frases escritas de forma sencilla y, lo que es más importante, una serie de conversaciones desencadenadas en función de la funcionalidad deseada.
Herramientas de gestión: criterios de aceptación
Se puede estar seguro de que una historia de usuario se ha implementado completamente cuando se demuestra que se han cumplido los criterios de aceptación. Pero, ¿qué son los criterios de aceptación?
Por criterios de aceptación en relación con una historia de usuario entendemos la definición de los parámetros que demuestran que se han alcanzado los resultados clave de la historia de usuario.
Los parámetros a los que nos referimos son las preguntas W (¿Quién? ¿Qué? ¿Por qué? ¿Cuándo? ¿Dónde? etc.).
Estos permiten comprender si una historia de usuario es eficaz y responde a todas las posibles necesidades cognitivas del lector.
Los criterios de aceptación son, por tanto, pruebas que se aplican a la historia de usuario para comprobar su adecuación en función de la finalidad de uso. En este contexto, debe prestarse especial atención a la identificación y mejora de las palabras clave, es decir, al uso de verbos, adjetivos y sustantivos pertinentes.
El principio INVEST
Una forma de comprobar la eficacia de su historia de usuario es utilizar el principio formulado por William Wake. INVEST también es un acrónimo y significa
- Independiente: la Historia de Usuario tiene su propia individualidad y es independiente de otras Historias de Usuario.
- Negociable: el contenido es implementable y continuamente mejorable. Se desarrolla mediante una colaboración entre el lector y los creadores de la historia. Por tanto, puede ser más detallada a medida que avanza su realización y prueba.
- Valiosa: la historia de usuario debe ser valiosa para el cliente. Debe ofrecer al lector una ventaja o beneficio y proporcionar indicaciones sobre cómo conseguirlo.
- Estimable: la evaluabilidad de una historia de usuario es el requisito previo y la condición para que sea negociable. La evaluabilidad de una historia de usuario también depende de su tamaño: cuanto más larga sea una historia, más difícil será evaluarla. Además, este criterio también depende de la experiencia del equipo: un grupo de expertos podrá evaluar una historia con más habilidad e inmediatez que los novatos.
- Pequeñas: las historias de usuario de calidad tienden a ser cortas. Por cierto, cuanto más corta es una historia, más evaluable es.
- Comprobable: la historia de usuario tiene criterios de aceptación y puede probarse. Si una historia es difícilmente comprobable por los usuarios, puede significar que no es lo suficientemente clara o que no ofrece un beneficio valioso al lector.
En definitiva, todos los puntos del principio INVEST sirven para evaluar la calidad de una historia de usuario y también para orientar su realización de modo que sea eficaz. Seguir los puntos propuestos en este modelo puede marcar la diferencia a la hora de determinar el éxito de su historia de usuario.
La jerarquía de las historias de usuario
Como deja claro el principio INVEST, las historias de usuario deben ser independientes entre sí. Sin embargo, en la práctica, a menudo se da el caso de que existen interdependencias entre varias Historias de Usuario. La dependencia de las Historias de Usuario puede ser de diferentes tipos. Por ejemplo, puede ser a nivel de contenido, técnico, reglamentario o normativo, temporal, etc.
La existencia de interdependencias entre Historias de Usuario a menudo no es evidente, por lo que es útil utilizar el Mapeo de Historias de Usuario para descubrirlas y eliminarlas.
Historias de Usuario vs. Historias Épicas
Existe una diferenciación básica dentro de la macrocategoría de historias de usuario. De hecho, dependiendo de la magnitud de los beneficios que proporcionan al lector, las Historias de Usuario también pueden ser llamadas Historias Épicas.
La diferenciación de estas dos categorías no es homogénea y siempre es la misma. Esto significa que no existe una norma reconocida según la cual una historia se clasifica automáticamente como de Usuario o Épica.
En términos generales, sin embargo, una Historia Épica puede definirse como una historia de usuario que posee un alto grado de conmoción técnica y especializada. En efecto, las Historias Épicas describen normalmente una funcionalidad de manera absolutamente detallada, técnica y específica.
Historias de usuario: ¿por qué utilizarlas?
Una Historia de Usuario es una herramienta práctica y poco costosa en términos de costes y de tiempo que dedicarle. Sin embargo, existen varias ventajas vinculadas a ella, como por ejemplo :
- Especialmente cuando es detallada, una Historia de Usuario puede apoyar el desarrollo iterativo de un sistema;
- Es fácil de entender y de recepción inmediata;
- Puede crearse, modificarse y sustituirse rápidamente.
Hoy en día, las historias de usuario son una de las herramientas favoritas para formular y discutir la funcionalidad de un producto o servicio. Por eso, conocer sus mecanismos y aprender a dominarlas es crucial para una implantación bien orientada de cualquier sistema.
Artículo traducido del italiano