Guía de Scrum | 19. Historias de usuario – ¿qué son?

La Historia de Usuario es una breve descripción de una nueva funcionalidad del Producto o su mejora. No contiene una solución técnica, sino que aborda preguntas sobre la funcionalidad: ¿Quién es el usuario? ¿Qué hace el Producto? ¿Y cuál es su propósito? La Historia de Usuario describe el producto en un lenguaje cotidiano o de negocios, aunque también señala las tareas del Equipo Scrum que están destinadas a mejorar el rendimiento del Equipo.

¿Qué son las Historias de Usuario? – tabla de contenido:

1. Introducción
2. Historia de Usuario. ¿De quién es la historia?
3. ¿Cómo usar las Historias de Usuario?
4. Criterios de Aceptación
5. Resumen

Introducción

La Historia de Usuario es la forma más común de formular las tareas realizadas por el Equipo Scrum. Una sola Historia de Usuario define una pequeña funcionalidad del Producto. Describe el objetivo parcial más pequeño y significativo del Producto. Por esta razón, las Historias de Usuario son muy breves.

Las Historias de Usuario se crean a lo largo de todo el tiempo de trabajo en el Producto. Se crean continuamente, desde el momento en que se toma la decisión de comenzar a trabajar, hasta la realización del Objetivo del Producto.

Crear Historias de Usuario es una tarea del Propietario del Producto. Basándose en una conversación con un Cliente, formula respuestas a preguntas que permiten crear la Historia de Usuario y las ingresa en el Backlog del Producto. Sin embargo, las Historias de Usuario reflejan no solo las necesidades del cliente.

Historia de Usuario. ¿De quién es la historia?

El Equipo Scrum crea una Historia de Usuario para definir las necesidades del Usuario, y por eso se redacta en lenguaje de negocios. En otras palabras, indica los beneficios que su implementación traerá al usuario del producto. Sin embargo, en el Backlog del Producto, también puede haber Historias de Usuario que describen las necesidades del Equipo de Desarrollo, por ejemplo, mejorar el flujo de trabajo entre los Desarrolladores, o describir las necesidades del Propietario del Producto, por ejemplo, organizar el Backlog del Producto. En tales casos, el Usuario en la Historia de Usuario es el Desarrollador y el Propietario del Producto.

Se puede describir una Historia de Usuario respondiendo a las preguntas 3W:

• ¿Quién?
• Está haciendo ¿Qué?
• ¿Por qué?

La Historia de Usuario se contiene entonces en una fórmula:

Como [tipo de usuario], quiero [hacer qué?] Porque [¿por qué?].

Ejemplos de Historias de Usuario sobre la funcionalidad de una tienda en línea escritas en esta forma se ilustran en la tabla a continuación:

Esta fórmula permite no solo formular una Historia de Usuario, sino también traducir relativamente fácil el lenguaje técnico al de negocios y viceversa. Como resultado, tanto los Desarrolladores como los Interesados ven claramente el Objetivo y las etapas de su progreso. También cubriremos la creación de buenas Historias de Usuario utilizando el método INVEST en un artículo separado en la serie de Guías Scrum.

¿Cómo usar las Historias de Usuario?

Crear una Historia de Usuario esquemática es solo el comienzo. Son señales y puntos de partida para discusiones sobre problemas y sus soluciones. Discutir las Historias de Usuario tiene lugar durante la Planificación del Sprint para aclarar qué problemas técnicos el equipo de Desarrollo añadirá al Backlog del Sprint.

Típicamente, en el espacio físico, las Historias de Usuario están escritas en pequeñas tarjetas de colores fijadas en el lugar de trabajo. Sin embargo, en el espacio digital, los pizarrones digitales, compartidos por el Equipo Scrum, funcionan mejor.

Guardar las Historias de Usuario de esta manera tiene varias ventajas porque:

• Destaca la autonomía de cada Historia de Usuario – cada una tiene un marco separado y puede ejecutarse independientemente de las demás
• Enfatiza la dinámica de las Historias de Usuario – el orden de su realización es renegociado por el Equipo Scrum y el orden actual de realización es visible en el tablero gracias a la disposición física de las tarjetas con Historias de Usuario
• Sirve como recordatorio – gracias a la representación visual de las Historias de Usuario, el Equipo Scrum tiene un letrero a la vista para recordarles el objetivo al crear soluciones detalladas.

El Equipo de Desarrollo estima el esfuerzo requerido para completar una Historia de Usuario en días, horas-hombre o Puntos de Historia.

Criterios de Aceptación

Una Historia de Usuario debe tener ciertos criterios de aceptación en el momento en que es aceptada para desarrollo por el Equipo de Desarrollo. Los criterios de aceptación determinan en qué momento el trabajo en una Historia de Usuario puede considerarse terminado.

De esta manera, tanto el cliente como los desarrolladores saben cómo su trabajo se traducirá en valor comercial. Típicamente, una Historia de Usuario se considera completada cuando el usuario especificado en ella puede realizar la acción descrita. Usando el ejemplo anterior, eche un vistazo a esta Historia de Usuario con el contenido:

Un cliente puede comprar una varita mágica con un solo clic.

Se considera completada cuando aparece un botón de “Comprar Ahora” funcional en la página de la tienda en línea, que utiliza la información de pago y envío predeterminada para el usuario que ha iniciado sesión.

Resumen

Una Historia de Usuario es una descripción concisa de una nueva funcionalidad o mejora del Producto. Sirve como el objetivo más pequeño expresado en lenguaje de negocios, es decir, desde la perspectiva del valor comercial y del usuario. Ayuda a definir claramente la tarea a realizar así como los criterios para su finalización.

Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.