Guía Scrum | 19. Historias de usuarios: ¿qué son?

Historia de usuario es una breve descripción de la funcionalidad de un nuevo Producto o su mejora. No contiene una solución técnica pero aborda cuestiones relativas a 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 comercial o cotidiano, aunque también señala las tareas del Equipo Scrum que tienen como objetivo mejorar el desempeño del Equipo.

¿Qué son las historias de usuario? - Tabla de contenido:

1. Introducción
2. Historia del usuario. ¿De quién es la historia?
3. ¿Cómo usar las historias de usuario?
4. Criterios de aceptación
5. Resumen

Introducción

User Story 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 de producto parcial significativo más pequeño. Por esta razón, las historias de usuario son muy breves.

Las Historias de usuario se crean durante 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. Basado en una conversación con un Cliente, formula respuestas a preguntas que permiten crear Historias de Usuario y las ingresa en el Product Backlog. Sin embargo, las historias de usuarios no solo reflejan las necesidades de los clientes.

Historia del usuario. ¿De quién es la historia?

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

Puede describir una historia de usuario respondiendo las preguntas de 3W :

• ¿Quién?
• está haciendo qué?
• ¿Por qué?

La historia de usuario se incluye en una fórmula:

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

En la siguiente tabla se ilustran ejemplos de historias de usuarios sobre la funcionalidad de una tienda en línea escritas en este formulario:

Esta fórmula permite no solo formular una historia de usuario, sino también traducir con relativa facilidad el lenguaje técnico al empresarial y viceversa . Como resultado, tanto los Desarrolladores como las Partes interesadas ven claramente el Objetivo y las etapas de su progreso. También cubriremos la creación de buenas Historias de Usuario usando el método INVEST en un artículo separado en la serie de Guías de 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. La discusión de las historias de usuarios se lleva a cabo durante la planificación del Sprint para determinar qué problemas técnicos agregará el equipo de desarrollo al Sprint Backlog.

Por lo general, en el espacio físico, las historias de usuarios se escriben en pequeñas tarjetas de colores fijadas en el lugar de trabajo. Sin embargo, en el espacio digital, las pizarras digitales, compartidas por el Equipo Scrum, funcionan mejor.

Guardar 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 se puede ejecutar independientemente de las demás.
• Enfatiza la dinámica de las historias de usuario : el equipo Scrum renegocia el orden de su realización y el orden actual de realización es visible en el tablero gracias a la disposición física de las tarjetas con las historias de usuario.
• Sirve como recordatorio : gracias a la representación visual de Historias de usuarios, el Equipo Scrum tiene una señal 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 con 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 mismo momento en que el Equipo de Desarrollo la acepta para su desarrollo . Los criterios de aceptación determinan en qué punto se puede considerar terminado el trabajo en una historia de usuario.

De esta forma, tanto el cliente como los desarrolladores saben cómo su trabajo se traducirá en valor comercial. Por lo general, una historia de usuario se considera completa 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 completa cuando aparece un botón "Comprar ahora" en funcionamiento 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 inició sesión.

Resumen

Una historia de usuario es una descripción concisa de una nueva funcionalidad o mejora del producto. Sirve como la Meta más pequeña expresada en lenguaje empresarial, es decir, desde la perspectiva del valor empresarial y del usuario. Ayuda a definir claramente la tarea a realizar, así como los criterios para su finalización.

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autora: Carolina Becker

Como Project Manager, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos