1. Las personas usuarias son lo primero
Como su nombre indica, una historia de usuario describe cómo un cliente o persona usuaria utiliza el producto; y se cuenta desde la perspectiva del usuario/a. Además, las historias de usuario son particularmente útiles para captar una funcionalidad específica, como buscar un producto o hacer una reserva. Si no sabemos quiénes son las personas usuarias o los clientes y por qué querrán utilizar el producto, no debemos de escribir ninguna historia de usuario. Primero, realicemos la investigación de usuarios necesaria, por ejemplo, observando y entrevistando a las personas usuarias. De lo contrario, corremos el riesgo de escribir historias especulativas que se basen en creencias e ideas, pero no en datos y evidencias objetivas.
2. Utilicemos “Personajes” para descubrir las historias correctas
Una gran técnica para captar sus conocimientos es trabajar con personajes. Basémonos en personajes de ficción. Por lo general, constan de un nombre y una imagen; características, comportamientos y actitudes relevantes; Y una meta. El objetivo es el beneficio que el personaje quiere lograr, o el problema que el personaje quiere que se resuelva mediante el uso del producto. Pero hay más:
los objetivos de los personajes nos ayudan a descubrir las historias correctas: preguntémonos qué funcionalidad debe proporcionar el producto para cumplir las metas de estos personajes.
3. Creemos historias de usuario de forma colaborativa
Las historias de usuario están pensadas como una técnica ligera que nos permite actuar con rapidez. No son una especificación, sino una herramienta de colaboración. Las historias nunca deben entregarse a un equipo de desarrollo. Deben integrarse en una conversación: el product owner y el equipo deben discutir juntos las historias de usuario. Esto permite capturar solo la cantidad mínima de información, reducir los gastos generales y acelerar la entrega. Podemos llevar este enfoque más allá y escribir historias de forma colaborativa como parte del proceso de preparación de la pila de producto. Esto aprovecha la creatividad y el conocimiento del equipo y da como resultado mejores historias de usuario. Si no podemos involucrar al equipo de desarrollo en el trabajo de la historia del usuario, entonces deberíamos considerar usar otra técnica más formal para capturar la funcionalidad del producto, como por ejemplo los casos de uso.
4. Mantengamos nuestras historias de usuario simples y concisas
Escribamos las historias para que sean fáciles de entender. Evitemos términos confusos y ambiguos y utilicemos una forma verbal activa. Concentrémonos en lo que es importante y omitamos el resto.
Como (personaje)
Yo quiero (que)
Así que (por/para qué)
Utilicemos plantillas cuando sea útil, pero no estemos obligados a aplicarlas siempre. Experimentemos con diferentes formas de escribir las historias para comprender qué es lo que mejor funciona para nosotros y el equipo.
5. Empecemos con las épicas
Una épica es una gran historia de usuario, incompleta y bruta. Por lo general, a lo largo del tiempo, se divide en varias historias de usuarios, aprovechando los comentarios de los usuarios sobre los primeros prototipos y los incrementos de producto. Podemos considerarlo como un titular y un marcador de posición para luego desarrollar historias más detalladas. Comenzar con épicas nos permite esbozar la funcionalidad del producto sin comprometernos con los detalles. Esto es particularmente útil para describir nuevos productos y características: Nos permite captar el alcance aproximado y nos da tiempo para aprender más sobre cómo abordar mejor las necesidades de las personas usuarias. También reduce el tiempo y el esfuerzo necesarios para integrar nuevas funcionalidades. Si tenemos muchas historias detalladas en la pila de producto, a menudo es complicado y se requiere mucho tiempo relacionar los comentarios con los elementos adecuados y conlleva el riesgo de introducir inconsistencias.
6. Refinemos las historias hasta que estén listas
Dividamos nuestras épicas en historias más pequeñas y detalladas hasta que estén listas: claras, factibles y comprobables. Todos los miembros del equipo de desarrollo deben tener una comprensión compartida del significado de la historia; la historia no debe ser demasiado grande y encajar cómodamente en un sprint; y tiene que haber una forma eficaz de determinar si la historia está terminada.
7. Agreguemos lo criterios de aceptación
Al dividir las épicas en historias más pequeñas, recordemos agregar los criterios de aceptación. Los criterios de aceptación complementan la narrativa: Permiten describir las condiciones que hay que cumplir para que se haga la historia. Los criterios enriquecen la historia, la hacen comprobable y garantizan que la historia pueda ser demostrada o lanzada a los usuarios y otras partes interesadas. Como regla general, es recomendable usar de tres a cinco criterios de aceptación para las historias detalladas.
8. Utilicemos tarjetas
Las historias de usuarios surgieron en Extreme Programming (XP), y la literatura de XP habla de tarjetas de historias en lugar de historias de usuarios. Hay una razón simple: las historias de usuarios se escribían en tarjetas de papel.
Este enfoque ofrece tres beneficios:
- Primero, las tarjetas de papel son baratas y fáciles de usar.
- En segundo lugar, facilitan la colaboración: todos pueden coger una tarjeta y anotar una idea.
- En tercer lugar, las tarjetas se pueden agrupar fácilmente en la mesa o en la pared para comprobar la coherencia y la integridad y visualizar las dependencias.
Incluso si las historias las almacenamos electrónicamente, vale la pena utilizar tarjetas de papel cuando escribamos nuevas historias.
9. Mantengamos las historias visibles y accesibles
Las historias quieren comunicar información. Por lo tanto, no los ocultemos en una unidad de red, la jungla de la intranet corporativa o una herramienta con licencia. Hagámoslos visibles, por ejemplo, colocándolos en la pared. Esto fomenta la colaboración, crea transparencia y hace que sea obvio cuando agregamos demasiadas historias demasiado rápido, nos quedaremos sin espacio en la pared y evidentemente para ello tendremos las aplicaciones o herramientas software..
10. No confiemos únicamente en las historias de los usuarios
Crear una excelente experiencia de usuario (UX) requiere más que historias de usuarios. Las historias de usuario son útiles para captar la funcionalidad del producto, pero no son adecuadas para describir la experiencia del usuario y el diseño visual. Por lo tanto, complementaremos las historias de usuario con otras técnicas, como story maps, diagramas de flujo de trabajo, guiones gráficos, bocetos y maquetas. Además, las historias de usuario no son buenas para captar los requisitos técnicos. Si necesitamos comunicar qué debe hacer un elemento arquitectónico como puede ser un componente o servicio, escribiremos las historias técnicas, usaremos un lenguaje de modelado como UML. Por último, vale la pena escribir historias de usuarios cuando se desarrolla software que es probable que se reutilice. Pero si deseamos crear rápidamente un prototipo o una maqueta desechable para validar una idea, es posible que no sea necesario escribir historias de usuario.
Recordemos: las historias de usuario no tratan de documentar requisitos; quieren permitirnos moverse con rapidez y desarrollar software lo más rápido posible, sin que se impongan costes adicionales.