Hemos empezado a utilizar la metodología Scrum en la empresa en la que trabajo y cada vez vamos cogiendolo más el truquillo. Pero un elemento clave que se nos atascó mucho son las historias de usuario. Por eso he decidido crear una guía fácil de entender para explicarlas claramente.
Las Historias de Usuario en la metodología Scrum es una técnica que plasma en una tarjeta los requisitos que va a tener el proyecto que se va a desarrollar. Estas historias van a ayudar a los integrantes del equipo a entender la dirección del proyecto y por eso deben claras y concisas y describir: que, quién y cómo se debe hacer.
Estas tarjetitas con la información del proyecto son muy importantes para su correcto desarrollo. A continuación te enseño como realizarlas y dominarlas para que las aproveches al máximo.
Gestiona todo tu scrum y tu equipo de trabajo desde una sola herramienta colaborativa. Aquí tienes una plantilla fácil de usar para todo lo que necesitas:
Plantilla de Historias de Usuario
En este artículo te voy a enseñar no solo a crear una historia de usuario sino que también vas a poder descargar una plantilla de historias de usuario lista para usar y con diferentes preguntas y trucos que te ayudarán a sacarle el mayor partido.
Aquí la puedes ver:
Ahora bien. Para entender el poder que tiene esta herramienta en las historias de usuario veamos realmente qué son dentro de la metodología ágil de scrum y cómo crearlas. Además, te voy a poner varios ejemplos reales y prácticos para que lo entiendas a la perfección.
¿Qué son las Historias de Usuario?
Las historias de usuario es una herramienta en scrum que basada en unas tarjetas en las que se plasma lo que se quiere conseguir, para quién y qué debe hacer el proyecto. Además, contiene una lista de requisitos por los que el proyecto se daría como finalizado con éxito.
El concepto es muy simple, pero muchas veces lo dejamos pasar por alto. En nuestro equipo las dejamos de lado y siempre íbamos como pollo sin cabeza. Esto cambió cuando empezamos a aplicarlas a través de una plantilla fácil de usar y entender.
Las historias de usuario las debe dirigir el Product Owner y podríamos decir que son breves descripciones de una funcionalidad del proyecto desde la perspectiva del usuario final. Igualmente incliyen los llamados “criterios de aceptación”, que son condiciones que deben cumplirse para que la historia se considere completada.
Un proyecto puede tener varias historias de usuario. De hecho, cada Sprint debería tener la suya propia.
Si quieres conocer más sobre la metodología de Scrum, aquí te dejo un artículo muy fácil de entender sobre qué es y para qué sirve scrum
Estructura de ejemplo de una historia de usuario scrum
Una historia de usuario consta de tres elementos principales: el título, la descripción y los criterios de aceptación.
El título debe ser descriptivo y centrado en el usuario, mientras que la descripción debe explicar brevemente el objetivo y el valor que se espera obtener. Por otro lado, los criterios de aceptación definen las condiciones necesarias para que la historia de usuario se considere completada y exitosa.
Ejemplo de estructura de user stories:
- Título: Yo Como [usuario], quiero [objetivo] para [beneficio].
- Descripción: [Breve explicación del objetivo y valor esperado].
- Criterios de aceptación:
- Criterio 1: [Condición necesaria para el éxito].
- Criterio 2: [Otra condición necesaria].
- Criterio 3: [Y otra condición necesaria].
Ahora veámoslo con ejemplos prácticos y reales:
Utiliza una plantilla de historia de usuario colaborativa y lleva tu scrum al siguiente nivel. Descubre cómo aquí:
Historias de Usuario Ejemplos
Si no conoces la metodología ágil de scrum debes de saber que las historias de usuario se realizan al principio del proyecto en la reunión de planificación del Sprint.
Previo a esta reunión el Product Owner ha mantenido conversaciones con los tomadores de decisiones de la empresa y con los usuarios del producto para tener una visión clara y poder guiar al equipo a la hora de crearlas. Así se verían:
Ejemplo de Historia de Usuario: Pongamos el ejemplo de una página web de una membresía que debe ser construida por una agencia de marketing para un cliente. Esta web se dividirá en diferentes Sprints con sus historias de usuario. Así se verían algunas de ellas:
Descripción: Yo como nuevo usuario, quiero poder registrarme en el sitio web para acceder a contenido exclusivo.
Criterios de aceptación:
- El usuario debe poder acceder al formulario de registro desde la página de inicio.
- El formulario de registro debe solicitar al usuario un nombre de usuario, correo electrónico y contraseña.
- El correo electrónico debe estar en un formato válido y no puede estar registrado previamente en el sistema.
- La contraseña debe tener al menos 8 caracteres y contener al menos una letra y un número.
- Al enviar el formulario, el usuario debe recibir un correo electrónico de verificación con un enlace para activar su cuenta.
- Después de hacer clic en el enlace de verificación, el usuario debe poder iniciar sesión en su cuenta correctamente.
Descripción: Yo como usuario, debo poder pagar a través de una página de carrito y tener una suscripción mensual.
Criterios de aceptación ejemplo:
- Debe haber un formulario con los datos de facturación del cliente
- La página debe tener integrado un datáfono virtual para tarjetas de crédito y débito
- Debe tener otros métodos de pago com Paypal, Google Pay, Apple Pay, etc.
- Debe tener un botón de “Suscripción”
De hecho he hablado sobre cómo aplicar scrum en marketing en este artículo que te puede ser interesante.
Cómo Crear las Historias de Usuario en Scrum (ejemplo práctico)
Las historias de usuario suelen seguir una estructura simple compuesta por tres elementos principales:
Paso 1: Las Tarjetas de la Historia de Usuario
La tarjeta, van a ser pequeñas notas (muchas veces se usan los famosos “Post-it” amarillos). Y van a ser el primer elemento de las historias de usuario donde brevemente se va a definir:
- Quién va a ser el beneficiario: Escribe en primera persona el beneficiario. Por ejemplo: “Yo como agente de ventas”
- Funcionalidades del proyecto: Escribe la continuación de la frase con la funcionalidad del proyecto que se debe resolver. Siguiendo el ejemplo anterior: “Quiero un sistema de ventas que automatice el conteo de las llamadas de ventas”.
- La finalidad del proyecto: Finalmente, acaba la frase con lo que se espera conseguir de este proyecto. Con el ejemplo: “Para saber el ratio de cierre de una llamada de ventas en un cliente de pago”
De esta manera tan simple se ha definido en una pequeña tarjetita y de una manera muy condensada la dirección y la visión del proyecto y va a permitir a todos los miembros del equipo de desarrollo empatizar y conocer mejor lo que se quiere conseguir. En nuestro ejemplo quedaría de la siguiente manera
Quien: «Yo como agente de ventas»
Quiero: «Quiero un sistema de ventas que automatice el conteo de las llamadas de ventas»
Para: «Para saber el ratio de cierre de una llamada de ventas en un cliente de pago»
Mira aquí sobre scrum aplicado a equipos de ventas
Pero espera, la cosa no queda ahí. Ahora debemos convertir esa tarjetita en algo más accionable, para ello escribiremos:
Paso 2: Los criterios de Aceptación:
Ahora que ya tenemos la historia de usuario inicial, debemos definir los pasos y criterios por los que debe pasar el usuario final para completar el proceso. Como siempre, es mejor verlo con un ejemplo.
1.- Debe haber una llamada
2.- El Agente de ventas debe descolgar la llamada desde el software de trackeo de llamadas
3.- Deberá explicar los argumentos clave al interesado
4.- Hará un cierre conveniente con una oferta irresistible
5.- Colgará y añadirá anotaciones a la llamada desde el software
6.- La llamada quedará registrada con los datos de la persona y sus inquietudes como cliente
De esta manera nos vamos acercando cada vez más a las acciones y el flujo de trabajo ideal del usuario que más tarde el Product Owner transformará en tareas y prioridades.
Paso 3: Conversación de las Historias de Usuario
La conversación es el elemento más importante en la creación de historias de usuario.
Aunque se pueda escribir mucha información en una tarjeta, nunca será tan efectivo como una conversación directa.
Un minuto de conversación puede ser más eficiente que una hora de escritura y envío de mensajes por correo electrónico. La conversación debe llevarse a cabo en la fase de planificación, con la presencia del Product Owner, quien es responsable de aclarar dudas y proporcionar respuestas.
A través de esta interacción, se pueden identificar nuevos detalles o mejoras que enriquezcan la historia de usuario.
Cómo convertir las historias de Usuario scrum en Tareas accionables
Una vez has hecho estos 3 ejercicios con tu equipo de trabajo y los usuarios del proyecto vais a tener una muy buena idea de por donde empezar y las tareas a llevar a cabo.
En nuestra empresa empezábamos a gritar y lanzar tareas a lo loco. Pero eso no ayuda nada. Para hacerlo correctamente, el Product Owner deberá coger las riendas de la conversación y definir las prioridades, los obstáculos y las tareas a realizar.
Para ello hay varias técnicas, pero la que usamos nosotros es la de INVEST. Para que una historia de usuario se pueda convertir en una tarea adecuada debe de ser:
- Independiente: Las historias de usuario deben ser lo más independientes posible, evitando dependencias entre ellas.
- Negociable: No es necesario detallar en exceso las historias de usuario antes de la conversación. Durante la planificación, se pueden discutir y ajustar los detalles según las necesidades y aportes del equipo de desarrollo.
- Valiosa: Cada historia de usuario debe generar valor por sí misma, sin depender de otras para ser significativa.
- Estimable: El equipo debe poder estimar la dificultad de implementación de una historia de usuario y compararla con otras para planificar adecuadamente el sprint.
- Pequeña: Las historias de usuario deben ser lo más pequeñas posible para asegurar su finalización dentro de un sprint y evitar el riesgo de no terminarlas a tiempo.
- Testeable: Debe ser posible verificar y comprobar si una historia de usuario está completa y cumple con los requisitos establecidos.
El Product Owner es fundamental en la creación de historias de usuario. Su responsabilidad principal es crear y mantener las historias de usuario claras, así como definir los criterios de aceptación de forma precisa. La presencia de un Product Owner comprometido garantiza que las historias de usuario sean bien definidas y adecuadamente priorizadas.
Finalmente este sería un ejemplo final de las tareas para el modelo de ventas basado en la trazabilidad de las llamadas de los agentes de ventas:
- Investigar las mejores soluciones de software, analizar precios y funcionalidades.
- Configurar el software con los requisitos detallados por los agentes de ventas
- Capacitar al equipo de ventas: organizar una jornada de formación
- Integración al CRM: Conectar el software a nuestro sistema de contabilidad y administración.
- Implementación gradual: Empezar por un agente de ventas e ir expandiendo a todo el equipo lentamente.
- Evaluación y Monitorización: Evaluar los ratios de conversión y si realmente mejora los procesos.
Finalmente, permíteme darte unos consejos para que la creación de tus historias de usuario sea lo más exitosa posible:
Características de una historia de usuario
Las historias de usuario son una herramienta fundamental en el desarrollo de software ágil. Para que sean efectivas, deben cumplir con ciertas características, tener criterios de aceptación claros y estar redactadas de manera concisa
Una historia de usuario debe cumplir con las siguientes características:
- Ser claras y comprensibles: Las historias de usuario deben ser fáciles de entender para todos los miembros del equipo.
- Ser relevantes y valiosas: Cada historia de usuario debe aportar valor al usuario final y estar alineada con los objetivos del proyecto.
- Ser independientes: Cada historia de usuario debe ser autónoma y no depender de otras para poder ser desarrollada.
- Ser estimables y medibles: Las historias de usuario deben poder ser estimadas en términos de esfuerzo y completitud.
- Ser negociables: Las historias de usuario deben ser flexibles y permitir modificaciones o negociaciones durante el proceso de desarrollo.
- Utilizar lenguaje sencillo: Evitar tecnicismos y utilizar un lenguaje claro y comprensible para todos los miembros del equipo.
- Enfocarse en el usuario: Centrarse en las necesidades y expectativas del usuario para garantizar que la historia resuelva un problema o mejore su experiencia.
Creación de criterios de aceptación para las historias de usuario
Los criterios de aceptación son una parte esencial de las historias de usuario. Estos criterios definen las condiciones que deben cumplirse para considerar que una historia de usuario está terminada. Algunos consejos para crear criterios de aceptación eficaces son:
- Especificar resultados medibles: Los criterios de aceptación deben ser específicos y cuantificables para facilitar la evaluación de la historia de usuario.
- Incluir casos de éxito y fallo: Es importante considerar diferentes escenarios para validar que la historia cumple todos los requisitos.
- Definir criterios de rendimiento y usabilidad: Además de los requisitos funcionales, es necesario establecer criterios que evalúen el rendimiento y la usabilidad del sistema.
- Utilizar un formato estructurado: Seguir una estructura consistente, como la plantilla modelo de historias de usuario en Scrum, facilita la comprensión y el seguimiento de las historias.
- Evitar ambigüedades: Las historias de usuario deben ser lo más específicas y descriptivas posible para evitar malentendidos y garantizar una correcta implementación.