¡Nuevo episodio de Scrum Manager Podcast! También disponible en Spotify e iVoox.
En este episodio vamos a hablar sobre cómo las historias de usuario son una herramienta esencial para desarrollar productos de calidad y cómo usarlas para asegurarnos de que se alineen con los objetivos de negocio y las necesidades del usuario.
Recordad que las transcripciones de todos los episodios estarán disponibles en el blog, e iremos subiendo a ritmo de sprint: cada par de semanas. No dudéis en sugerirnos temas sobre los que os gustaría profundizar en los comentarios.
En la encuesta del episodio anterior la práctica ganadora fue agile inception y estamos preparando contenido para compartir pronto. ¡Gracias por vuestro feedback!
Transcripción
¡Hola y bienvenidos! Hoy hablaremos de cómo usar las historias de usuario para ser más eficientes, y alinear las necesidades de nuestros usuarios y nuestro negocio. ¡Empezamos!
¿Qué es una historia de usuario?
Con frecuencia llamamos “historia de usuario” a cualquier requisito ágil. Pero siendo más rigurosos solemos distinguir los requisitos por tamaño y definición, de manera que se clasifican, de más grandes y abstractos a menores y más concretos, de la siguiente forma: temas, epics, historias de usuario y tareas. Los temas son requisitos de nivel muy general, pertenecen a la visión del proyecto. Al definirlos más se dividen en epics e historias de usuario, con los que se empieza a componer la pila del producto. Y que más tarde descompondremos en tareas de la pila del sprint, priorizadas, estimadas y bien definidas.
Una historia de usuario como tal es una descripción de una funcionalidad que queremos incluir en el proyecto, y explicada desde el punto de vista del usuario. Se hace así para entender no sólo qué queremos construir sino por qué: qué valor aporta.
Suelen tener una estructura que incluye:
- Un título breve y descriptivo.
- La descripción de la funcionalidad desde el punto de vista del usuario.
- Los criterios de validación y verificación que el cliente necesita para considerar la historia terminada y aceptable.
- También pueden contener a veces información adicional según el modelo de implementación: prioridad, riesgo, tamaño, etc.
No obstante, es interesante saber que en su origen las historias de usuario no tenían ningún formato estándar. Aparecieron como alternativa a los documentos de requisitos, que nadie leía en detalle y que desembocaban en proyectos fallidos, en gran medida por mala comunicación. El propósito era crear requisitos en un formato simple, descriptivo, y que ayudase al equipo a recordar una conversación sobre lo que había que construir. Es decir, el énfasis estaba puesto más en las interacciones que en la documentación. Jeff Patton enfatiza en User Story Mapping que la palabra «historia» tenía el propósito de poner énfasis en la importancia de hablar, por encima de los documentos escritos. La historia de usuario resultante, el papel, no es la descripción de la funcionalidad entera: es un recordatorio.
En el mismo libro aparece una anécdota en la que, para recordar que era necesario traducir una página al japonés en un proyecto, el equipo apuntó simplemente un kanji en una nota adhesiva. Este ejemplo se usa para enfatizar que no todo tiene por qué encajar en un formato concreto. Mientras la historia cumpla su función para el equipo, sirve. Pero, como veremos más adelante, usar una plantilla o un formato para las historias de usuario cuando sabemos por qué lo estamos haciendo también tiene sus ventajas.
Existe un truco mnemotécnico para recordar cómo sacar el máximo provecho de las historias de usuario: las 3 Ces. Las propuso por primera vez Ron Jeffries en eXtreme Programming. Las 3 Ces son: Card, Conversation y Confirmation. Vamos a verlas con un ejemplo.
De la teoría a la práctica
Nuestra empresa ha decidido crear una red social para entusiastas de los deportes al aire libre. Partimos de un estudio de mercado: sabemos que existen grupos dedicados a esto en otras redes, pero hemos observado que hay necesidades que éstas no satisfacen.
Nos encontramos en la reunión de planificación de nuestro primer sprint. El product owner ya ha redactado las epics que componen el product backlog, las ha priorizado y ordenado en consecuencia. Ahora con el equipo tiene que extraer lo que se desarrollará durante el sprint.
Aquí ya encontramos la primera C: card. Una «card» es una promesa de una conversación. Suele ser una epic, que todavía está sin discutir ni estimar. Una idea para el proyecto.
Una posible epic de nuestro backlog que tendríamos que discutir y descomponer en historias y tareas es:
- Desarrollar un sistema de perfiles de usuario que permita compartir información sobre sus experiencias e intereses.
Es importante, como señala Mike Cohn, que haya un equilibrio en la conversación entre los aspectos técnicos y los aspectos de negocio.
Por supuesto, habrá muchas más epics. Por ejemplo, puede interesarnos incluir en un futuro funcionalidades para que nuestros usuarios contacten con servicios de emergencia, por si ocurre un accidente mientras practican deporte. Podemos dejar que esto sea, de momento, una nota que diga simplemente «funcionalidades SOS» para no olvidarnos de hablar de ello en un futuro. Una «card».
Por ahora hemos priorizado crear el sistema de perfiles en el primer sprint. El siguiente paso es descomponer esta epic en historias de usuario.
¿Cómo crear una historia de usuario?
Mediante la segunda C: Conversación. Existen distintos formatos para elaborarlas, el más famoso es Connextra. En 2001 esta empresa británica popularizó una plantilla para crear historias de usuario que sigue el siguiente esquema:
Como <rol>, quiero <capacidad> para <beneficio>.
Así, por ejemplo, nuestra epic «desarrollar un sistema de perfiles de usuario que permita compartir información sobre sus experiencias e intereses» podría descomponerse en las siguientes historias:
- Como usuario, quiero poder crear un perfil en la red social para que otros usuarios puedan conocerme a mí y a mis intereses.
- Como usuario, quiero poder especificar mis intereses y actividades al aire libre en mi perfil para compartir con otros usuarios lo que me gusta hacer y poder conectar a través de intereses compartidos.
- Como usuario, quiero poder tener mi perfil privado, para que solo mis amigos puedan verlo.
Pero algo falla. Podríamos sacar más provecho de estas historias, añadiendo más contexto. El rol, la capacidad y los beneficios descritos no nos permiten entender bien las necesidades de los diferentes perfiles de usuario. Seguir la plantilla es útil, pero tenemos que adaptarla más.
Vamos a probar a especificar mejor quiénes son nuestros usuarios. Para ello podemos crear perfiles, también llamados «user personas». Aquí van un par de ejemplos que vamos a usar:
- Diego: es un estudiante de 25 años apasionado de la escalada y el senderismo. Le encanta programar aventuras al aire libre con amigos. Es activo en redes sociales y suele publicar fotos y vídeos.
- Sofía: es una madre trabajadora de 35 años con dos hijos. Le encanta ir de camping y hacer kayaking. Le interesa encontrar actividades al aire libre para hacer con su familia y amigos. Es un usuario más casual que a veces sube fotos a Instagram.
Podemos crear historias más específicas mediante los perfiles:
- (Diego) Como estudiante universitario de 25 años a quien le encanta el senderismo y la escalada, quiero poder buscar a otros usuarios que tengan intereses y actividades similares, para poder encontrar nuevos amigos con los que emprender aventuras al aire libre.
- (Sofía) Como madre trabajadora de 35 años con dos hijos a la que le encanta acampar y hacer kayak, quiero poder buscar actividades al aire libre que sean aptas para familias y estén cerca de mi casa, para poder planificar viajes divertidos y fáciles para mi familia.
Como vemos, con historias más específicas y adaptadas, podemos garantizar que las necesidades de los usuarios estén cubiertas. Como quedan un poco largas al describir las funcionalidades así, es bueno dar a las historias un título breve pero descriptivo, con el que recordarlas o referirnos a ellas más rápido.
La de Diego podría titularse: «Hacer amigos para aventuras al aire libre» y la de Sofía «Actividades en familia».
Durante la Conversación iremos apuntando criterios de aceptación para dar como válidas y terminadas las historias. Después entrará en juego la tercera C: Confirmación. El propietario del producto debe revisar los criterios de aceptación como han quedado apuntados al final de la reunión y confirmar que el equipo ha entendido y recogido lo que se necesita adecuadamente. A veces estos criterios se pueden convertir en escenarios de pruebas o testing. Por ejemplo, para la primera historia, la de “quiero poder buscar a otros usuarios” podemos crear criterios de aceptación en forma de pruebas con usuarios reales:
- Los usuarios son capaces de buscar y filtrar a otros usuarios según sus intereses.
- Son capaces de enviar, aceptar y rechazar solicitudes de amistad.
- Son capaces de comunicarse entre sí a través del chat.
A estos criterios, además, habría que añadirle la definición de Hecho de nuestra empresa. La definición de Hecho (Definition of Done en inglés) es lo que debe cumplirse para que podamos dar una historia por completada. Incluye los criterios de aceptación de esa historia en concreto y otros que son aplicables a todas las historias de usuario. Por ejemplo: que hayamos probado la funcionalidad y resuelto bugs, y que haya quedado documentada de alguna forma para uso interno.
Las historias de usuario son requisitos ágiles. No contienen toda la información necesaria para desarrollar la funcionalidad que queremos, sino que sirven para recordar la conversación entre el equipo y el propietario del producto. Porque habremos hablado de los usuarios, de lo que imaginamos que necesitan y por qué, de cómo podríamos desarrollarlo, y la historia debe servir para ayudar al equipo a refrescar la memoria durante el sprint. De modo que podemos seguir un formato concreto o no.
La plantilla que hemos visto, Como <rol>, quiero <capacidad> para <beneficio>, es útil para guiar la conversación. Podemos tener una discusión mucho más rica así, de la que tendríamos si enfocáramos el problema sólo desde el punto de vista de la funcionalidad. Por ejemplo, si pensáramos «tenemos que construir un buscador de usuarios» en lugar de «queremos que nuestros usuarios puedan hacer amigos con los que organizar actividades al aire libre».
Nos ayuda a entender la necesidad del usuario para plantear mejores soluciones y criterios de aceptación. Pero hay que tener cuidado de no convertir al equipo en lo que se conoce como «zombies de las plantillas». El término aparece en Adrenaline Junkies and Template Zombies, y se refiere a equipos que se dejan llevar por las plantillas en lugar de reflexionar. No hay que empeñarse en hacer que todo encaje en el formato estándar de historia de usuario. Es normal que una funcionalidad de seguridad, o de backend, no encaje, por ejemplo. Si no nos preocupamos podemos acabar con atrocidades tipo:
«Como product owner, quiero que todos los miembros del equipo se registren en Trello para sincronizarnos mejor.»
Esto no hace ninguna falta. Pero el formato se ha vuelto tan popular que se llega a pensar que si no se escriben las tareas así no son historias de usuario, y esto es un error. De hecho, se llega a escribir dejando de lado, por ejemplo, el título breve que resume la historia a golpe de vista, cuando ésta puede resultar más útil incluso que la descripción extendida. Incluso se llega a no hablar, y a enviar requisitos redactados en formato Connextra por correo.
Las historias de usuario son una herramienta engañosa: parecen sencillas, pero para aprovecharlas bien hace falta un uso consciente, reflexión y práctica. Esperamos que estos consejos os hayan servido para entender mejor su función. Si os interesa el tema, en el blog compartiremos también algunos recursos adicionales.
Volveremos con el próximo episodio en lo que se tarda en hacer un sprint: un par de semanas. Hasta entonces podéis encontrarnos en Twitter, LinkedIn y en scrummanager.com.
¡Mucha suerte con vuestros proyectos y hasta la próxima!
Contenido adicional sobre historias de usuario
- Manual .pdf sobre historias de usuario.
- Apuntes de User Story Mapping.
- Apuntes de 50 ideas rápidas para mejores historias de usuario.