Historias de Usuario

Clase 18 de 26 • Curso de Scrum Profesional

Historias de Usuario

<Apertura/> (Minuto 0:00 - 1:00)

A menudo, creamos soluciones para necesidades que no existen. Las historias de usuario no son una simple recolección de requisitos, sino que son el medio ideal para identificar los problemas y necesidades reales que debemos resolver. En esta clase, aprenderemos a escribir historias de usuario que generen verdadero valor.

Ideas clave (Minuto 1:00 - 4:30)

Las historias de usuario son una forma de describir una funcionalidad desde la perspectiva del usuario o cliente. No son un contrato o un documento técnico; son la base de una conversación para asegurar que el equipo entienda el "porqué" detrás de lo que está construyendo.

La forma estándar de escribir una historia de usuario es: Como un <tipo de usuario>, quiero <una funcionalidad> para que <el beneficio o valor>.

Veamos cada componente:

Como un <tipo de usuario>: Define a la persona que necesita la funcionalidad.
Quiero <una funcionalidad>: Describe lo que el usuario quiere lograr.
Para que <el beneficio o valor>: Es la razón de fondo por la que el usuario quiere esa funcionalidad. Este componente es el más importante, ya que define el valor que se espera entregar.

Las características de una buena historia de usuario se pueden resumir en el acrónimo INVEST:

Independiente: Debe ser autónoma y no depender de otras historias para su desarrollo.
Negociable: Es un punto de partida para una conversación, no un contrato rígido.
Valiosa: Debe entregar valor real al cliente o al negocio.
Estimable: El equipo debe poder calcular el esfuerzo necesario para completarla.
Pequeña: Debe ser lo suficientemente pequeña como para ser completada en un Sprint.
Testable: Debe poder verificar o probar que se ha cumplido.

Las historias de usuario son refinadas por los Desarrolladores y el Product Owner de forma colaborativa. Esta es una actividad que se realiza durante el Sprint.

¿Cuál es la diferencia entre casos de uso e historias de usuario?

Tradicionalmente en el desarrollo de aplicaciones, sistemas de información y otros escenarios, hemos escuchado hablar de los casos de uso. Un caso de uso es un documento detallado que explica cómo un usuario interactúa con un sistema para lograr un objetivo específico. A diferencia de una historia de usuario, que se centra en el valor para el cliente y fomenta la conversación, un caso de uso tiende a ser más formal y exhaustivo, detallando las precondiciones, el flujo de eventos, las postcondiciones y las posibles excepciones.

Veamos algunas diferencias entre los casos de uso y las historias de usuario (ver tabla)

<Práctica/> (Minuto 04:30 - 06:00)

Ahora, vamos a practicar escribiendo algunas historias de usuario para nuestra aplicación de aprendizaje de idioma en inglés.

Veamos un ejemplo de una historia de correcta:

Como un estudiante que viaja frecuentemente, quiero poder acceder a las lecciones sin conexión a internet, para que pueda seguir aprendiendo sin importar dónde me encuentre. Esta es una buena historia de usuario porque se centra en el usuario, la funcionalidad y el valor que le entrega.

Veamos un ejemplo de una historia incorrecta:

El sistema debe permitir que la base de datos se conecte al servidor principal. Esto no es una historia de usuario. ¿Por qué? Porque no se centra en una necesidad del cliente. Es una tarea técnica, un requisito de la infraestructura, no un problema que el usuario necesita que se resuelva. No tiene un "Como un...", un "quiero..." o un "para que...".

Ahora que sabes la diferencia, veamos algunos ejemplos correctos adicionales:

Como un estudiante que se prepara para una entrevista laboral en inglés, quiero tener acceso a un módulo de simulacros de entrevista con feedback inmediato de mi pronunciación, para que pueda prepararme mejor y aumentar mi confianza.

Como pueden ver, estas historias se centran en el usuario, la funcionalidad y, lo más importante, el valor que se entrega.

Cierre (Minuto 6:00 - 7:00)

Las historias de usuario nos ayudan a pensar en el problema antes de proponer la solución. Te invitamos a que escribas tres historias de usuario teniendo en cuenta el product backlog construido en la clase pasada para el caso de negocio que venimos desarrollando, utilizando el formato y la guía del ejemplo práctico.

En la próxima clase, abordaremos como gestionar las historias de usuario.