¿Qué son las Historias de Usuario? | Cómo usarlas + Plantillas

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

1. 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.
2. Conversación (conversation). La historia debe permitir un diálogo entre quien expresa la necesidad y quien la satisface.
3. 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:

1. Feature: Proporciona una descripción de alto nivel de una de las funciones de software y agrupa SCENARIOs relacionados.
2. Scenario (Escenario): Es un ejemplo concreto que contiene una regla de negocio.
3. 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).
4. 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.
5. 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.
• 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”.