Desarrollar un gran proyecto es más complicado de lo que puede parecer desde fuera. ¿Qué tenemos que crear? ¿Para qué lo hacemos? ¿Qué problema tenemos que resolver de los usuarios? ¿Es esta la mejor solución a este problema? Para resolver todas estas preguntas tenemos que ser capaces de ponernos en la piel de los usuarios y eso no es siempre tan sencillo. Para ello, llegan los frameworks como Design Thinking y Agile que nos ayudan a empatizar mejor con el usuario para hacer los productos con mejor encaje problema-solución. Y durante ese camino nos apoyamos en las historias de usuario que permiten a los equipos de desarrollo estar siempre alineados con las necesidades de los usuarios. En este post te contamos qué son las historias de usuario, cómo crearlas y te damos 3 plantillas para que sea mucho más fácil. ¿Arrancamos? ¡Vamos allá!
Te puede interesar: Master en Project Management
¿Qué son las historias de usuario?
También conocidas como User Stories o simplemente US, las Historias de Usuario son pequeñas descripciones de los requerimientos de un cliente. Se utilizan comúnmente en entornos de desarrollo y frameworks ágiles y bajo metodologías como Scrum y Kanban para escribir los requisitos y las pruebas de validación.
En el Scrum, las historias de los usuarios mejoran la estimación y planificación de los demás sprints, mientras que en el Kanban se introducen en el backlog para aprender a gestionar el trabajo en curso (WIP, o Work In Progress) y perfeccionar aún más el flujo de trabajo.
En el Scrum, el propietario del producto (Product Owner o PO), el gestor del producto o el gestor del programa es quien debe redactarlas, idealmente, ya que es quien mantiene comunicación con los stakeholders. Y en el Kanban, cada miembro del equipo debe escribir las historias de usuarios para generar un proyecto ágil.
Este formato aparece en XP (eXtreme Programming) por Kent Beck en 1999, pero se populariza definitivamente con Mike Cohn, en su libro “User Stories Applied: For Agile Software Development”, lanzado en 2004, que fija el patrón para definirlas. Este patrón se estructura en tres partes:
- Como: persona que expresa una necesidad
- Quiero/Necesito: la necesidad requerida
- Para: valor obtenido, contexto de la necesidad
¿Para qué sirven las historias de usuario?
Las historias de los usuarios describen el por qué y el qué hay detrás del trabajo diario de los miembros del equipo de desarrollo, mediante un enfoque visual que permite ver, priorizar y evaluar los requisitos.
Asimismo, son una forma muy práctica de definir el alcance de un proyecto sin necesidad de utilizar un lenguaje técnico. Otros beneficios de las historias de usuario:
- Ayuda a alinear expectativas de todos los participantes
- Fomenta el trabajo en equipo y la integración de expertises
- Aumenta la satisfacción del usuario
- Impulsan soluciones creativas
- Reducen errores a futuro
¿Por qué usar las historias de usuario?
Para proyectar en grande una idea es necesario contar con diversas estructuras que ayuden a organizar los entregables desde el de mayor importancia hasta los subsecuentes. También, entre toda la planeación, debes ser capaz de responder a los cambios y abrirte a las opiniones de los demás.
Aquí es donde los epics, las historias y las iniciativas son, exactamente, las metodologías ágiles y de DevOps que ayudarán a su empresa a organizar el trabajo y lograr un equilibrio saludable entre estructura, flexibilidad y eficacia. Usaremos el storytelling para contar la historia de nuestro producto.
- Historias: Como ya vimos, son breves indicaciones o solicitudes escritas desde el punto de vista del usuario final.
- Epics (proyectos de mayor volumen): Son grandes cantidades de trabajo que se pueden desglosar en un número de tareas más pequeñas, ya sea desde historias hasta subhistorias.
- Iniciativas: Son conjuntos de epics e historias de usuario que conforman la totalidad del proyecto.
El aspecto más importante en la elaboración de historias de usuario es el “para”, pues lo que siempre debemos cubrir es la “funcionalidad”. El resto del patrón es una forma de responder al “para”.
DTSWETM Tip
¿Cómo construir una historia de usuario?
Debes describir el rol, la funcionalidad y el resultado esperado en una frase corta. Debe venir acompañada (al reverso) de los criterios de aceptación, estos permiten definir las pruebas a realizar para poder verificar su aceptación.
Debe haber hasta un máximo de 4 criterios por historia, redactado también en una frase el contexto, el evento y el comportamiento esperado ante ese evento.
De esta forma, la historia de usuario entregará el valor esperado por el Product Owner.
Te compartimos 3 estructuras fundamentales para la redacción de historias de usuario:
1# Regla de las 3’Cs
- Tarjeta (card). La historia debe ser lo suficientemente breve como para que su definición entre en una tarjeta, a lo mucho en una o dos frases en un lenguaje común y entendible por el usuario.
- Conversación (conversation). La historia debe permitir un diálogo entre quien expresa la necesidad y quien la satisface.
- Confirmación (confirmation). La historia debe contener los elementos necesarios para determinar que se ha entregado el valor buscado por la necesidad.
2# Como [perfil], [quiero] [para]
La estructura más básica consiste en estos tres elementos, que en inglés serían Role–Feature–Reason. Recuerda que uno de los beneficios de las historias de usuario es que coloca al cliente en el
centro de todos los procesos, por lo mismo se tienen distintos frentes de los cuales se rescatan soluciones ágiles e innovadoras.
Aquí te va un ejemplo:
Como director de ventas, quiero registrar los ingresos y cantidades que me solicitan mis clientes para trazar una estrategia comercial con mis proveedores.
3# Given – When – Then
Otra de las estructuras utilizada en el desarrollo de software se crea mediante pruebas de aceptación, donde “Given” (Dado) especifica el escenario y/o las precondiciones; “When” (Cuando) explica las condiciones de las acciones que se van a ejecutar; y “Then” (Entonces) arroja el resultado esperado y/o las validaciones a realizar.
En la metodología Agile, se añaden otros elementos como la prioridad, la estimación en días de desarrollo y las dependencias para ayudar al equipo a gestionar y priorizar de manera efectiva. Este lenguaje se deriva del BDD (Behavior Driven Development), una estrategia de desarrollo dirigida por comportamiento. Cuenta con un léxico particular, del cual vamos a tomar las 5 palabras clave:
- Feature: Proporciona una descripción de alto nivel de una de las funciones de software y agrupa SCENARIOs relacionados.
- Scenario (Escenario): Es un ejemplo concreto que contiene una regla de negocio.
- Given (Dado): Se utiliza para describir el contexto inicial del sistema: la escena del escenario. Su objetivo es poner el sistema en un estado concreto antes de que el usuario (o sistema externo) comience a interactuar con el sistema (en los WHEN).
- When (Cuando): Se utiliza para describir un evento o una acción, desde una persona que interactúa con el sistema o un evento desencadenado por otro sistema.
- Then (Entonces): Se utiliza para describir el resultado esperado. La definición de un THEN debe usar una aserción para comparar el resultado real (lo que el sistema realmente hace) con el resultado esperado (lo que se supone que debe hacer el sistema).
A continuación, un ejemplo:
- Feature: Búsqueda en Google
- (Aquí insertas tu historia de usuario) Como usuario web, quiero buscar en Google para responder mis
dudas.
- (Aquí insertas tu historia de usuario) Como usuario web, quiero buscar en Google para responder mis
- Scenario: Pantalla de búsqueda simple en Google
- Given: Un navegador web en la página de Google
- When: Se introduce la palabra de búsqueda “agile”
- Then: Se muestra el resultado de “agile”
Ejemplos de historias de usuario
Otro de los beneficios de las User Stories es que pueden escribirse con distintos niveles de detalle. La longitud determina la funcionalidad que se desea abarcar. Cuando se llegan a tener grandes historias de usuario generalmente pasan a categoría de “épicas” (Epics). ¿Cuál de las siguientes crees que sea épica?
- Como usuario, quiero hacer una copia de seguridad de mi memoria USB.
- Los usuarios de iPhone necesitan acceder a una vista vertical de la alimentación en vivo cuando utilizan la aplicación móvil.
- Como gestor de productos, quiero crear y editar una lista con los miembros de mi equipo, para añadirlos a todos a una invitación sin tener que añadirlos individualmente.
- Los usuarios de equipos de escritorio necesitan un botón de visualización en pantalla completa en la esquina inferior derecha del reproductor de video.
- Como gestor comercial, quiero poder comprender el progreso de mis compañeros, para poder informar sobre nuestros éxitos y fallos a la dirección.
- Como usuario de banca móvil, quiero invitar a mis amigos a que usen su aplicación, para que podamos aprovechar el sistema de bonificación de puntos.
- Los usuarios de Android deben estar vinculados al Apple Store.
- Como gestor de recursos humanos, quiero poner las historias de usuario en un tablero digital, para que todos podamos ver la que estamos discutiendo en una reunión en línea.
- Los usuarios digitales deben organizar sus perfiles de trabajo para sentirse con mayor control de su identidad.
- Como gestor de contenido, quiero invitar a los miembros de mi equipo y a un máximo de 10 personas más a una reunión en línea, para que podamos colaborar y detallar las estrategias
que se implementarán el siguiente trimestre.
Plantillas para trabajar las historias de usuario
Es hora de redactar tus propias User Stories. En las siguientes imágenes encontrarás cómo practicarlas desde las diferentes guías.
Lo importante es que puedan ayudarte a conocer y entender no solo las necesidades de tu cliente, sino también las del usuario final, o sea “el cliente de tu cliente”.
¡Ya tienes suficientes herramientas para mejorar tu gestión de proyectos! Recuerda que las historias de usuario son cruciales para que todo el equipo tenga una buena comunicación y se eliminen los sesgos individuales a la hora de priorizar o desarrollar funcionalidades a los diferentes productos.
Si quieres seguir profundizando en la gestión ágil de proyectos, te recomendamos el Master en Project Management de IEBS Digital School que te permitirá conviértete en el catalizador de la cultura ágil de tus organizaciones y los proyectos.