20 Ejemplos de historias de usuarios y mejores prácticas

¿Cómo empiezas a diseñar una aplicación o un sitio web de éxito que vaya a ser un éxito entre tus usuarios? Las historias de usuario son tu mejor aliado si las combinas con una herramienta de wireframing.

Las historias de usuario nos ayudan a encajar a nuestros user persona en el contexto del producto que estamos diseñando. Mientras que la biografía de un user persona describe su vida y sus penas, la historia de usuario describe cómo utilizan una función de tu producto, ¡en términos sencillos! En el entorno ágil, los Propietarios de Producto, junto con los diseñadores de UX, tienden a escribir historias de usuario en fichas para pasarlas por el equipo de diseño y suscitar conversaciones. También podemos escribirlas digitalmente, utilizando Office o Google Docs para incluirlas en el backlog de Scrum. El hecho de que estén escritas en un lenguaje sencillo y desprovisto de toda jerga técnica significa que el equipo de diseño se siente menos restringido por los tecnicismos. Tienen más oportunidades de ser creativos con sus ideas de diseño de características. Sigue leyendo para ver algunos ejemplos de historias de usuario.

Una historia de usuario es una breve descripción de lo que debe hacer un producto, para quién es y por qué es necesario. Normalmente, se escribe en una o dos frases y sigue un formato sencillo para que sea fácil de entender y actuar en consecuencia. Una historia de usuario típica tiene este aspecto «Como ( user persona), quiero (una acción) para que (un beneficio/un valor)». Esta estructura ayuda a los equipos a comprender lo que necesita el usuario sin entrar en detalles técnicos.

Trabajar con historias de usuario tiene varias ventajas demostradas, razón por la que muchos equipos ágiles de todo el mundo las adoptan. He aquí algunas de las razones clave por las que los equipos ágiles dan prioridad a las historias de usuario.

Una de las principales ventajas de las historias de usuario es que dividen los ambiciosos y enormes alcances del producto en conjuntos de características más pequeños y alcanzables. Las historias de usuario son simplemente una breve declaración de los objetivos del usuario en sus propias palabras. Ayudan a los grupos a evitar enfangarse en detalles y protocolos, y en tecnicismos y procedimientos.

Las historias de usuario son brillantes a la hora de ayudar a los equipos a priorizar qué características construir primero. Cuando se utilizan como elementos del backlog, facilitan la organización y división de tareas o requisitos de características en sprints. Esto es crucial para que la redacción de historias de usuario y las prácticas ágiles de historias de usuario sean eficientes.

Las historias de usuario proporcionan a los equipos ágiles criterios concretos con los que realizar pruebas. Cada historia debe tener un resultado claro y demostrable, que garantice que la historia de usuario cumple el resultado deseado. Esto ayuda a los equipos a medir el rendimiento y los resultados con mayor eficacia durante cada sprint.

Las historias de usuario ayudan a identificar el valor que determinadas características ofrecerán a los usuarios. Los equipos ágiles pueden centrarse en las características más importantes e inmediatas que se necesitan por adelantado, lo que conduce a un trabajo más eficiente y rentable para los clientes y las partes interesadas, al tiempo que beneficia al usuario.

Como las historias de usuario carecen de la jerga técnica que se encuentra en muchos otros documentos de desarrollo de productos, abren al equipo a una especulación más creativa. Esto fomenta un diálogo más creativo y flexible entre los equipos de desarrollo y diseño. Con las historias de usuario, el énfasis se desplaza de las características y los detalles técnicos al punto de vista del usuario y los usos potenciales del producto. Las partes interesadas no técnicas que deseen saber en qué características se está trabajando y la dirección del proyecto también encontrarán muy útil este método.

Las historias de usuario pueden dar vida a las user persona, implicando en el proyecto a estas personas ficticias pero basadas en la vida real. Es como tener a representantes de miles o millones de usuarios guiando al equipo de desarrollo sobre lo que necesitan, en lugar de que el equipo simplemente se lo imagine. Las historias de usuario pueden combinarse para formar mapas de historias de usuario, una productiva técnica ágil en la que todas las historias se organizan para crear un calendario de desarrollo y una lista de prioridades.

La forma en que los equipos ágiles escriben las historias de usuario suele variar según las distintas organizaciones y equipos. Para escribir historias de usuario con éxito, siempre debes tener en cuenta los siguientes elementos para proporcionar a tu equipo una imagen completa de lo que se necesita exactamente en cada fase del desarrollo del producto: – Usuario
– Acción
– Beneficio Con estos tres elementos, puedes redactar una breve historia de usuario sobre la característica(requisito del producto) que necesita tu persona y por qué la necesita. Normalmente escribimos la historia de usuario con la siguiente estructura: Como usuario de ____, quiero ____ para poder ____. Supongamos que quieres crear una aplicación de conducción social que permita a los conductores ver dónde están sus amigos. También les permite publicar actualizaciones sobre retrasos de tráfico, accidentes o patrones meteorológicos utilizando su voz. Podrías rellenar la estructura anterior así:

A continuación, podrías incluir lo que se denomina un criterio de aceptación (en el que profundizaremos más adelante), que enumera las especificaciones técnicas necesarias para garantizar que se satisfacen las necesidades del usuario. Podrían incluir lo siguiente

• La aplicación debe reconocer el comando de voz del usuario para iniciar una nueva publicación
• La aplicación debe leer los mensajes de los usuarios
• La aplicación debe pedir al usuario que confirme que quiere publicar
• Las notificaciones deben enviarse a los amigos de la red

Pero, ¿qué pasa cuando necesitas escribir más de una historia de usuario, por ejemplo? Al fin y al cabo, tu aplicación o sitio web tendrá múltiples características y tus historias de usuario serán breves. ¿Cómo las clasificas en subcaracterísticas? La respuesta es escribiendo historias épicas.

Las historias épicas te ayudan a pintar un cuadro más amplio resumiendo una acción compleja compuesta de acciones más pequeñas. En este sentido, la historia épica de usuario es como una visión general de una característica del producto. Las historias épicas se escriben exactamente igual que las historias de usuario, sólo que son menos específicas. He aquí un ejemplo:

Este épico ejemplo de historia de usuario puede subdividirse en ejemplos de historias de usuario más específicos para la misma aplicación, como los siguientes:

O:

Por último, siempre debes escribir tus historias de usuario desde el punto de vista de tu user persona. Por ejemplo, no escribas una historia que, para que pueda ser probada, primero haya que desarrollar o diseñar otra función. Cuando haces esto, te desvías hacia un territorio peligroso que, en el mundo ágil, se denomina «punto muerto». Es muy parecido al «jaque mate» en ajedrez. Es cuando no tienes adónde ir. El autor de Starting Agile, Mark Shead, dio el siguiente ejemplo de una historia de usuario vaga y mal escrita durante su vídeo Historias de usuario ágiles:

En este caso, la base de datos ya tendría que existir, con lo que el resultado de la historia de usuario (almacenar información) sería codependiente de la base de datos.

Muchos equipos que se equivocan en las historias de usuario suelen acabar en este punto muerto o estancados. El cliente les pide una actualización, y ellos responden diciendo que, para empezar a desarrollar la aplicación, primero deben terminar el «trabajo de configuración». Pero lo ideal sería que el «trabajo de preparación» nunca existiera. Si las historias de usuario no pueden poner en marcha la acción desde el principio, probablemente lo estés haciendo mal. Las grandes historias de usuario pueden sostenerse por sí solas de forma independiente y también combinarse bien con otras para dar una imagen de conjunto del producto. A veces una idea puede no ser mala, simplemente está mal presentada, como en el caso del ejemplo de historia de usuario mal escrita anterior.

En primer lugar, y por encima de todo, antes de empezar a escribir tus historias de usuario, es vital que lleves a cabo la investigación de usuarios adecuada y definas tus user persona. ¿Por qué? Porque son precisamente estas personas de usuario en las que se basarán tus historias de usuario. Los personajes de usuario son el primer paso para escribir una historia de usuario con éxito, porque si no sabes quién es el usuario, ¿cómo es posible escribir tu historia desde el punto de vista del usuario?

Cuando se trata de la técnica de redacción de historias de usuario, hay tres requisitos básicos que debes tener en cuenta antes de empezar. O, si estás intentando vender la idea a otras partes interesadas. Se conocen como las 3 C:

• Tarjeta
• Conversación
• Confirmación

El objetivo de las historias de usuario es proporcionar una declaración sencilla en una tarjeta. Rápido y sencillo. La siguiente «C» es Conversación: el objetivo de las historias de usuario es suscitar una conversación creativa y la colaboración entre equipos ágiles. Por último, la última «C» es «Confirmación», que se refiere a los criterios de aceptación que podemos probar una vez que hayamos construido la función de la historia de usuario.

El método INVEST es una regla práctica estupenda para guiarte en la redacción de las mejores historias de usuario posibles. El método INVEST es un mnemotécnico para las siguientes buenas prácticas:

Las historias de usuario, aunque a menudo se incluyen en las epopeyas, también deben ser comprensibles como piezas independientes.

Las historias de usuario deben ofrecer un alto grado de flexibilidad. Por eso no deben incluir tecnicismos específicos. Al fin y al cabo, la flexibilidad es la naturaleza del entorno scrum.

La historia de usuario debe ofrecer valor, tanto al equipo como a tus user persona. Debe dar a tu equipo una idea clara de los objetivos que debe alcanzar una función cuando la diseñen y desarrollen. Y para el usuario, significa un producto que satisface sistemáticamente sus necesidades.

Debería ser posible estimar la cantidad de trabajo necesaria para una característica propuesta en una historia de usuario. Esto te ayudará a asignar los puntos scrum pertinentes a la tarea del backlog y a gestionar el tiempo de forma eficaz.

Una historia de usuario debe ser breve y memorable. Sólo dos líneas sobre lo que ese usuario quiere conseguir con una función concreta de tu producto. Si se trata de una descripción general de tu aplicación o de una categoría de funciones, escribe una epopeya y divídela en subhistorias. Lo ideal es que la historia de usuario quepa en una iteración. Tampoco deberías mencionar ningún detalle sobre el diseño de la UI en una historia de usuario.

Como ocurre con la mayoría de las cosas en el proceso de desarrollo, tus historias de usuario deben ser fácilmente comprobables, con métricas claras y deducibles para los indicadores clave de rendimiento. Aquí es donde suelen entrar en juego los criterios de aceptación.

A continuación, lo mejor que podemos aconsejar a la hora de escribir con regularidad grandes historias de usuario es utilizar una plantilla. Es una forma brillante de asegurarte de que tú y cualquier persona de tu equipo que escriba historias de usuario cubráis siempre el quién, el qué y el por qué. Estos son los detalles que necesitas para asegurarte de que captas toda la información necesaria de la forma más concisa posible.

Existen muchas plantillas digitales útiles que también pueden imprimirse o utilizarse en Jira u otro sistema kanban. Pero lo mejor es que las plantillas también pueden tener muchos otros campos que pueden ser útiles, como puntos scrum y un área para escribir tus criterios de aceptación. Utilizar una plantilla para epopeyas compuesta por muchas subhistorias también puede ser una forma estupenda de organizar una serie de microcaracterísticas que giren en torno a una macrocaracterística mayor.

Las historias candidatas son un paso opcional a la hora de escribir historias de usuario. Son las historias que tu equipo escribe primero para iniciar el proceso cuando intentas averiguar qué es lo que quiere el usuario basándote en sus personas. Este paso opcional puede ser una forma estupenda de hacer una lluvia de ideas utilizando fichas físicas en una reunión. Ni siquiera es necesario que las historias de candidatos sigan la estructura típica de las historias de usuarios reales. Las historias candidatas que tu equipo elabore con éxito pueden desarrollarse posteriormente hasta convertirse en historias de usuario reales.

Los criterios de aceptación son esenciales para las historias de usuario. Especifican lo que hay que hacer para que una historia se considere completa, garantizando que el producto satisface las necesidades del usuario.

El objetivo principal de los criterios de aceptación es esbozar las condiciones que deben cumplirse para que se acepte una historia de usuario. Ayudan a asegurarse de que todos, desde los usuarios hasta los desarrolladores, entienden lo que debe hacer el producto final.

Hay varias formas de escribir los criterios de aceptación. Un método popular es el formato Dado/Cuando/Cuando:

• Dada una situación concreta,
• Cuando ocurre algo,
• Entonces debería producirse un cierto resultado.

Otro método sencillo es la Lista de control. En ella, enumeras en viñetas todas las condiciones que deben cumplirse. Este método es claro y fácil de utilizar.

Redacta los criterios de aceptación de forma directa y clara. Haz que tu lenguaje sea comprensible. Asegúrate de que los requisitos pueden ponerse a prueba para cuantificarlos y validarlos. Involucra a todos los miembros del equipo en el proceso para obtener sus opiniones.

Incluir criterios de aceptación bien definidos en tus historias de usuario mejora la redacción de las mismas. Proporciona directrices claras para el desarrollo y las pruebas, asegurando que el producto final satisface las necesidades del usuario. Se trata de una parte importante del método ágil de historias de usuario, que ayuda a que los proyectos se mantengan en el buen camino y alineados con los objetivos del usuario.

Una forma de decidir si una característica de una historia de usuario es comprobable es escribir criterios de aceptación para cada una de las que crees. A veces, los criterios de aceptación pueden incluir una lista de varias variables que deben cumplirse una vez desarrollada la característica. Un ejemplo podría ser

Los criterios de aceptación podrían ser algo como lo siguiente «Después de registrarse, al usuario se le debe mostrar una opción en la pantalla de inicio de sesión para iniciar sesión con su cuenta de Google». A veces, sólo con leer la propia historia de usuario, puede resultar obvio cuáles deben ser los criterios de aceptación. Sin embargo, por cortos o largos que sean, siempre es una buena práctica redactar los criterios de aceptación. Esto evita que tu equipo caiga en hábitos perezosos y nunca escriba ninguno. Lo mejor es que ya estés pensando en los criterios de aceptación cuando estés escribiendo tu historia de usuario. Si no puedes pensar en los criterios de aceptación, significa que la función no puede probarse. Esto significa que tal vez quieras replantearte esa característica en concreto. Si, por otra parte, los criterios de aceptación son demasiado largos para incluirlos en una ficha, deberías considerar la posibilidad de dividirlos en otra historia de usuario, o tal vez en una historia épica. Todas estas son cosas en las que puedes pensar a la hora de redactar los criterios de aceptación.

Las historias de usuario son como el corazón de un proyecto de equipo, ya que les guían para centrarse en lo que sus clientes quieren de verdad, convirtiendo las grandes ideas en pequeños pasos factibles.

Estas historias de usuario se escriben desde la perspectiva del usuario, asegurándose de que el equipo entiende lo que el usuario necesita y por qué. Esto mantiene a todos centrados en crear un producto que sirva realmente a sus usuarios.

Las historias de usuario son como bloques de construcción, que se añaden a la lista general de tareas del equipo. A continuación, la persona que dirige el equipo decide qué historias son las más importantes para sus clientes, determinando cuáles deben abordarse en primer lugar. Cuando el equipo se reúne para planificar, elige de esta lista maestra las historias en las que se centrará a continuación.

Cada historia tiene una serie de condiciones, como una lista de comprobación, que deben cumplirse antes de que la historia se considere «terminada». Esto garantiza que todo el mundo esté de acuerdo en cómo debe ser el trabajo terminado, manteniendo el listón alto durante todo el proyecto.

Las historias de usuario ofrecen grandes ventajas para los proyectos ágiles. Desglosan los grandes proyectos en tareas más pequeñas y realizables, facilitando al equipo la organización y el seguimiento. Esto significa que se hace más y que las cosas avanzan más rápido.

También facilitan mucho la comunicación, tanto dentro del equipo como con otras personas implicadas en el proyecto. Un lenguaje sencillo garantiza que todos entiendan los objetivos del proyecto y lo que hay que hacer, manteniendo a todos en la misma línea.

Además, las historias de usuario fomentan la colaboración entre los miembros del equipo. Inician debates sobre las formas más eficaces de lograr los resultados deseados, generando ideas y soluciones innovadoras. Este enfoque colaborativo garantiza que el producto se adapte y evolucione en función de las necesidades y comentarios reales de los usuarios.

Veamos algunos ejemplos de historias de usuario en proyectos ágiles y cómo funcionan en situaciones reales:

• Para un sitio web: «Como visitante, quiero suscribirme fácilmente al boletín para recibir actualizaciones y promociones».
• Para una aplicación móvil: «Si estoy utilizando la aplicación y olvido mi contraseña, quiero una forma sencilla de restablecerla».
• Para una tienda online: «Cuando compro en Internet, quiero filtrar los artículos por precio para encontrar fácilmente cosas que se ajusten a mi presupuesto».

Cada uno de estos ejemplos se centra en lo que quiere el usuario y en el valor que obtiene al utilizar esa función concreta. Así es como los equipos construyen productos que la gente encuentra realmente útiles y quiere seguir utilizando.

En el desarrollo de productos, comprender a los usuarios es crucial. Para obtener este conocimiento, se utilizan varias herramientas. Aquí tienes en qué se diferencian y cuándo utilizarlas.

Las necesidades de los usuarios son declaraciones sencillas de lo que los usuarios quieren hacer o de los problemas que quieren resolver. Estos objetivos son la base para construir y priorizar características.

Cuándo utilizarlas: Utiliza las necesidades de los usuarios al principio del desarrollo del producto para definir lo que éste debe hacer.

Los tipos de usuario son descripciones detalladas de los distintos tipos de personas que podrían utilizar tu producto. Son como personajes basados en la investigación, e incluyen información como la edad, los hábitos, los deseos y los retos.

Cuándo utilizarlos: Crea perfiles de usuario al principio del proceso de diseño para comprender mejor a tus usuarios y hacer que el producto se adapte a sus necesidades específicas.

Las historias de usuario son explicaciones paso a paso de cómo un tipo de usuario interactúa con el producto para alcanzar un objetivo. Muestran cómo se utiliza el producto y pueden poner de manifiesto posibles problemas.

Cuándo utilizarlas: Utiliza las historias de usuario durante la fase de diseño para determinar cómo interactúan los usuarios, encontrar áreas de mejora y facilitar el uso del producto.

Las narrativas visuales son representaciones visuales de las historias de usuario, que a menudo combinan imágenes y palabras para mostrar claramente la experiencia del usuario.

Cuándo utilizarlas: Utiliza imágenes de usuarios durante las revisiones de diseño y las presentaciones para facilitar la comunicación, obtener comentarios y mejorar el producto basándote en lo que ven y experimentan los usuarios.

Necesidades del usuario: Definir lo que debe hacer el producto.

Tipos de usuario: Representar distintos tipos de usuarios y fundamentar las decisiones de diseño.

Historias de usuario: Ilustran cómo interactúan los usuarios y facilitan el uso del producto.

Imágenes de usuario: Mejoran la comunicación y visualizan la experiencia del usuario.

Hemos incluido tanto ejemplos tradicionales de historias de usuario escritas en fichas o notas adhesivas, como ejemplos digitales de historias de usuario que pueden compartirse fácilmente en una plataforma online. Algunos incluso vienen en forma de plantillas descargables, como archivos de Word y Excel. Vamos a sumergirnos:

Este ejemplo de historia de usuario Plan de Producto tiene cinco secciones importantes. La primera es el Título de la historia. Para ello, puedes indicar el nombre de la función de la que va a tratar la historia, como «reseñas de libros».

En la sección Prioridad, puedes asignar una prioridad de baja a media o alta. Es importante asignar prioridades a tus elementos del backlog, ya que algunas características tendrán más demanda, según tu matriz de trazabilidad de requisitos. Junto a Prioridad está la sección Estimación. Aquí puedes indicar el tiempo que crees que tardará el equipo en entregar esta característica. Aquí puedes asignar el número pertinente de puntos scrum. A continuación, en este ejemplo de historia de usuario, tienes la propia sección de la historia de usuario y, por último, los criterios de aceptación. Los criterios de aceptación suelen escribirse en el reverso de la copia índice, pero como ésta es una copia digital bidimensional, los criterios de aceptación están claramente escritos justo debajo, como una especie de conclusión. A algunos les puede resultar muy útil tenerlo todo incluido en la misma página.

Este documento Word editable es fácil de usar y viene con instrucciones claras para cada cláusula y criterio de aceptación. En nuestra opinión, las instrucciones que vienen después de cada cláusula de la historia de usuario, junto con las de los criterios de aceptación, son bastante sencillas de seguir.

¿Por qué es importante tener estas instrucciones en tu plantilla de historias de usuario? Porque si tu equipo lleva un tiempo sin escribir historias de usuario, o tienes que trabajar en muchas historias, es bueno tener este tipo de instrucciones para que actúen como estímulo. Sirven como recordatorio útil de la calidad de la información que debe ir en cada cláusula.

¿Qué mejor manera de agrupar información en tablas que Excel? Esta plantilla excel de historia de usuario también es un poco diferente en el sentido de que, además de los campos habituales, también te da la oportunidad de rellenar otra información importante.

Los campos extra que puedes encontrar en este ejemplo de historia de usuario incluyen el valor de negocio del usuario, el cálculo del riesgo, el coste del retraso y el trabajo más corto ponderado primero. Esta información extra también podría ser útil, dependiendo del tipo de características del producto en el que estés trabajando, o de los tipos de clientes o empresa para los que trabajes.

En este ejemplo de historia temática basado en Excel, tienes una columna para la estimación de la prioridad, los criterios de aceptación y también una columna «Lanzamiento» para una fecha de lanzamiento.

Las columnas de este ejemplo de historia de usuario están bien ordenadas, con los temas dispuestos verticalmente y los tipos de columnas horizontalmente. Sería una plantilla estupenda para una historia épica compuesta de múltiples subhistorias.

Hablando de ejemplos de historias de usuario épicas, quizá quieras echar un vistazo a esta plantilla de historias de usuario épicas. Proporciona una forma estupenda de agrupar subhistorias por sus historias épicas. Cada característica de la historia épica se enumera verticalmente, con las columnas correspondientes al usuario, la acción o deseo y el beneficio. A continuación, la última columna consiste en una disposición vertical de historias de usuario en subfilas envueltas en cada celda.

La forma en que está dispuesta esta historia de usuario épica consigue mostrar una clara jerarquía entre las historias épicas y sus múltiples y detalladas historias de usuario. Esto hace que sea muy fácil de escanear y obtener una visión rápida de todas las características que hay que aplicar o desarrollar para satisfacer al usuario.

Esta plantilla descargable de historia de usuario de Powerslides nos muestra otra forma ordenada de organizar nuestras historias de usuario. Estas tarjetas pueden mostrarse en una presentación de PowerPoint, así como imprimirse y distribuirse. También nos gusta la clara división de las secciones más importantes: la historia de usuario y la identificación del usuario, así como algunas secciones que la diferencian de otros ejemplos.

En la sección de historia podemos ver la historia de usuario y los criterios de aceptación. Sin embargo, debajo de la sección ID de usuario hay un área donde puedes adjuntar una foto de tu user persona, junto con algunas casillas de verificación para el tipo de función en la que se centra y campos para la prioridad y la estimación del tiempo.

Lo que nos gusta de esta historia de usuario a la antigua usanza es su sencillez y la forma en que devuelve las cosas a lo básico. A veces puedes necesitar redactar una historia rápidamente para una característica de un producto o una visión general rápida de características como una epopeya.

Este sencillo y tradicional ejemplo de historia de usuario nos muestra exactamente lo fácil que puede ser. Lo bueno de las fichas es que también puedes escribir los criterios de aceptación en el reverso, y así la ficha de historia de usuario se puede ir pasando por el equipo.

Aquí tenemos un ejemplo tradicional de una historia de usuario que refleja cómo se podría escribir una historia de usuario en una ficha. La historia muestra claramente lo que el usuario quiere conseguir y por qué quiere conseguirlo. En este caso, quieren cancelar sus reservas para no perder todo su dinero en caso de que se produzca una situación.

En el reverso de la tarjeta se enumeran todos los criterios de aceptación. Muestra todas las funciones de la aplicación de las que hay que ocuparse para que los beneficios del usuario y los beneficios de los objetivos empresariales se cumplan satisfactoriamente.

Este ejemplo de historia de usuario de aplicación bancaria es una forma estupenda de explicar de forma sucinta una función necesaria y por qué el usuario la necesita. Va directo al grano sobre quién es el usuario y qué necesita conseguir. De hecho, una de las cosas que tiene de bueno es que incluso alude a uno de los dolores que el usuario de una aplicación bancaria (en este caso, el titular de una tarjeta de crédito) puede sentir normalmente, como preocuparse por el saldo pendiente de su tarjeta de crédito, mantener una buena puntuación crediticia y mantenerse fuera de los números rojos.

El usuario de este ejemplo de historia de usuario quiere pagar su saldo, así que lo primero que podría hacer el equipo de diseño es empezar a trabajar en una solución que le dé un acceso más o menos instantáneo al saldo de su tarjeta de crédito. O bien debe ser lo primero que vean al abrir la aplicación, o bien debe haber una opción clara para ver el saldo de esa tarjeta que esté a un toque de distancia.

Nuestro siguiente ejemplo de historia de usuario de Whizible es también una plantilla que puedes descargar para que tú y tu equipo tengáis una ventaja. Esta plantilla te permite escribir una lista de varias historias de usuario en la misma tarjeta. Las columnas horizontales de la parte superior muestran la frase formulada de la típica historia de usuario, lo que significa que sólo hay que rellenar los espacios en blanco.

Esto sin duda puede ahorrarte tiempo a la hora de redactar varias historias de usuario y puede ayudarte a ir directamente al grano. Por ejemplo, a simple vista podemos deducir de este ejemplo de historia de usuario que el gestor de contenidos tiene la siguiente historia: «Como gestor de contenidos, quiero obtener un informe semanal de análisis de contenidos para poder controlar la eficacia del redactor de contenidos».

Elegimos este ejemplo de historia de usuario de Amazon porque nos da una idea del tipo de historia que se espera en un entorno ágil en una gran empresa tecnológica multinacional. Lo interesante es que es muy sencillo. No hay jerga técnica y cualquier persona de cualquier disciplina puede entenderla, que es de lo que tratan las historias de usuario.

En este ejemplo, el usuario está registrado con ellos y quiere comprar un kindle para su amigo. Una de las formas en que el equipo podría responder a esta historia, dependiendo de quién sea su user persona, podría ser incluir una sección de regalos en la pantalla de inicio. Podría decir algo así como «El regalo de cumpleaños perfecto». Por otro lado, podrían optar por mostrar un mensaje que indique al usuario que puede enviar regalos al instante mientras navega por artículos como el kindle. Otra acción que podrían querer seguir es asegurarse de que el cliente puede añadir nuevas direcciones o elegir su lista de direcciones actual de forma rápida y sencilla. Si utilizas Amazon, ¡verás que esto es así!

En este ejemplo, obtenemos una visión de cómo son las historias de usuario enumeradas en un backlog en un entorno ágil de desarrollo de productos.

Como podemos ver aquí, los elementos del backlog se agrupan por orden de prioridad y las tareas se representan con historias de usuario. En cada historia de usuario, podemos observar los diferentes puntos scrum otorgados para indicar cuánto trabajo supondrá cada característica.

Nos gusta este sencillo ejemplo de historia de usuario de BBC Sport. Lo que nos gusta de él es el hecho de que en realidad transmite mucha información en pocas palabras, que es exactamente lo que se supone que debe hacer una buena historia de usuario.

En este ejemplo, la BBC estaba pensando en añadir un botón de compartir a sus artículos deportivos, con la idea de que los lectores puedan compartir noticias relacionadas con el deporte y también conocer las opiniones de sus amigos. Es completo, transmite mucha información y la lógica es sencilla. Definitivamente justifica la necesidad de un botón de compartir y apunta a que alguien ha investigado bastante sobre su base de usuarios antes de escribir esta historia de usuario.

Este ejemplo de historia de usuario de Easy Agile es un poco diferente. En primer lugar, observamos que es notablemente fácil para los ojos. Para empezar, cada fila alterna entre el color y el blanco, para separar fácilmente los conceptos y facilitar el escaneo. Las secciones izquierda y derecha de la tarjeta, es decir, las instrucciones y la fórmula de la frase, están codificadas por colores verde y azul.

A continuación, las instrucciones de la izquierda de este ejemplo de historia de usuario nos sirven de ayuda con las categorías «Quién», «Qué» y «Por qué». Nos ayudan a pensar en la historia desde el ángulo empresarial, como «¿Para quién lo estamos construyendo?», «¿Quién es el usuario?» y «¿Cuál es la intención?». Si se duplicara este ejemplo, resultaría increíblemente útil y serviría de fácil estímulo para empezar a escribir historias de usuario.

He aquí algunos ejemplos de historias de usuarios de un sitio web de viajes. Nos presentan cuatro historias diferentes que nos dan una idea de las distintas funciones que podrían desarrollar para ayudar a sus user persona a alcanzar sus objetivos. Sin embargo, un problema que vemos es que tres de las cuatro son incorrectas. Bueno, no tanto incorrectas como incompletas. ¿Por qué? Porque las historias de usuario siempre deben indicar la razón de «por qué» quieren completar una acción.

La función siempre debe proporcionar algún beneficio al usuario. Esto ayuda a tu equipo a dar prioridad a las funciones específicas que van a aportar un valor y un significado reales a tus usuarios. Y unos usuarios felices significan un producto de éxito y un negocio feliz. El primer ejemplo habla de reservas de hotel. Una versión mejor y más completa podría decir Como usuario, quiero reservar una habitación de hotel cerca del centro de la ciudad, para no tener que viajar lejos cada día. Es poco probable que el usuario no tenga en mente una ubicación concreta para el hotel, se dé cuenta o no. Añadir la parte del «por qué» te ayuda a idear soluciones más creativas que podrían ayudar al usuario, como mostrarle hoteles, en función de su presupuesto, que estén más cerca del centro de la ciudad o del aeropuerto. Esto podría evitar que el usuario tuviera que salir de la página y buscar las direcciones de los hoteles en los mapas de Google y comprobar las distancias. De lo contrario, podría ser cualquier otro sitio web de viajes que no ofrezca una función claramente útil para el usuario. El último ejemplo de historia de usuario, sin embargo, es completo y útil para el equipo de diseño; muestra exactamente lo que quiere el usuario: poder guardar reservas anteriores y evitar un esfuerzo adicional de introducción de datos. También puede ayudar a elaborar unos criterios de aceptación mejores y más rígidos.

Agile USA, con su ejemplo de historia de usuario en nota adhesiva para un gestor de cuentas, resume sucintamente lo que debe contener este tipo de entregable. Se trata de un ejemplo bastante sencillo que muestra cómo la información vital para guiar al equipo de diseño y desarrollo puede resumirse fácilmente en una simple nota adhesiva. Lo que nos gusta de este tipo de ejemplo es que no intimida y es fácilmente comprensible para cualquiera.

Te permite seguir una fórmula sencilla para redactarlas, lo que es necesario cuando se trata de creatividad, especialmente cuando se te pide que escribas una historia tras otra de características de producto el día de redacción de historias.

Decidimos incluir este ejemplo de historia de usuario de Alexander Cowan porque refleja claramente el grado de reflexión que conlleva crear incluso la historia de usuario más básica. Escribir una historia de usuario no consiste simplemente en plantear una situación hipotética que implique a un usuario hipotético. Por el contrario, debe basarse en investigaciones reales y en user personas. Este ejemplo de historia de usuario nos ayuda a basarnos en esa información recordándonos los fundamentos de por qué estamos escribiendo esa historia en primer lugar.

Las indicaciones de este ejemplo son estupendas para ayudarte a elaborar una historia de usuario que refleje la user persona en cuya creación tú y tu equipo habréis invertido esfuerzos. Lo que también nos gusta de este ejemplo de user persona es el hecho de que las indicaciones también ayudan a llegar a los criterios de aceptación preguntando «¿cómo sabremos si funciona?».

Esta aplicación de fitness trata de ayudar a los usuarios a mantenerse motivados haciendo un seguimiento de sus entrenamientos diarios. La historia de usuario es sencilla: «Como aficionado al fitness, quiero hacer un seguimiento de mis entrenamientos diarios para poder controlar mis progresos y mantenerme motivado».

El objetivo es ayudar a los amantes del fitness a controlar sus progresos y mantenerse motivados. La aplicación debe permitir a los usuarios registrar distintos tipos de entrenamientos y ofrecerles resúmenes semanales y mensuales. De este modo, los usuarios pueden ver cómo lo están haciendo y mantener alta su motivación.

Además, debe enviar notificaciones para recordar a los usuarios sus horarios de entrenamiento. Esta historia de usuario es clara, procesable y se centra en la necesidad de seguimiento y motivación del usuario.

Imagina un jnior diseñador freelance que busca un entorno acogedor para trabajar mientras disfruta de una taza de café. La historia de usuario describe: «Como diseñador freelance junior, quiero tomarme un café en un ambiente acogedor mientras trabajo, por lo que espero un pedido rápido, espacio libre para mí con el portátil y la posibilidad de cargar el dispositivo».

Esta historia destaca las necesidades del autónomo, haciendo hincapié en la importancia de un espacio de trabajo cómodo con servicio rápido, amplio espacio para el portátil y acceso a instalaciones de carga. Centrándose en estos detalles, la cafetería puede crear un ambiente acogedor que atraiga a autónomos y trabajadores a distancia.

Esta historia de usuario se centra en una persona que quiere optimizar sus compra en el supermercado experiencia. La historia del usuario es: «Como persona que trabaja duro, quiero hacer la compra sin perder tiempo para poder dedicarme más tiempo a mí misma».

Esta historia destaca la necesidad del usuario de un proceso de compra eficiente y rápido, haciendo hincapié en la importancia de ahorrar tiempo y mejorar la comodidad. Se centra en ofrecer una experiencia de compra ágil que permita al usuario gestionar sus tareas con eficacia mientras disfruta de más tiempo personal.

El medio adecuado para tu historia de usuario y la información correcta que debes incluir en ella dependerán de tu organización, del tamaño y la escala de tu proyecto y de la complejidad de las funciones que estés diseñando. Sea cual sea el medio que elijas para transmitir tu historia de usuario, lo más importante que debes tener en cuenta es la investigación. Una vez que hayas realizado una investigación adecuada de los usuarios y definido los perfiles de tus personas, estarás listo para redactar tus historias de usuario. Si sigues las buenas prácticas indicadas en este post y te inspiras en los ejemplos y plantillas mostrados (o incluso los descargas), estarás bien encaminado para escribir una historia de usuario excelente.