fbpx

Orígenes de «User Story»: Extreme Programming «XP» (1998), Agility

Una historia de usuario (User story en inglés) es la descripción funcional utilizada en las metodologías ágiles para especificar el desarrollo de una característica, expresando para quién es y cómo aporta valor.

Normalmente lo escribe el Product Owner, para definir una necesidad con los equipos de desarrollo, de acuerdo con una estructura que permita expresar de forma atómica (INVEST), de manera sistemática y clara el interés de la funcionalidad.

Existen diferentes modelos de formulación; En general, como parte de un proyecto, los PO acordarán una «plantilla» clara y compartida que incluya las dimensiones «quién», «qué» y «por qué»:         

Como <quién>, quiero <qué> para <por qué>.

El interés de <por qué> es expresar claramente el valor de la historia de usuario para el usuario, lo que permitirá, en particular, priorizarlos en orden de importancia.

El <quién> no indica necesariamente un tipo de usuario final del sistema, sino cualquier rol relacionado con el producto: usuario final de un determinado segmento, tester, desarrollador, administrador, etc.

Las historias de usuarios, en su formato anglosajón, a menudo vienen en dos formas:         

Como <definir el perfil del usuario>, quiero <describir la característica o feature> para que <describa el valor>

        Para <describir el valor>, como <definir el perfil del usuario>, quiero <describir la característica o feature>

Esta segunda formulación obliga al Product Owner a comenzar definiendo el valor de su historia y evitando más fácilmente que la dificultad de repetir el <qué> en el <por qué>

Alguno ejemplos:

  • Como usuario avanzado de MacOS, quiero poder ver el tamaño de todas las carpetas para que pueda ser más eficiente al limpiar mi disco duro.
  • Como usuario de iPhone, quiero recibir informes de entrega de mis SMS enviados para que pueda saber cuándo mis amigos han recibido mis SMS.
  • Como administrador de detección de fraudes, quiero evitar que los usuarios creen más de 5 cuentas desde los mismos dispositivos Android para poder limitar la cantidad de promociones que damos.

El alcance de la historia de usuario a menudo va más allá  de su simple descripción, y puede encajar en un grupo más amplio de historias de usuario que constituyen de forma coherente un grupo mayor (ver: Épica). La organización global de todas estas funcionalidades constituye un «Story Mapping», que permite organizar de forma coherente muchas más Historias de usuarios atómicas y reunirlas en subconjuntos para distinguir las funcionalidades: Funcionalidades mínimas para el mercado.

Una historia de usuario a menudo se complementa con una descripción de las reglas de administración, idealmente en coautoría entre el PO, el equipo de diseño y el equipo de desarrollo. En términos más generales, el PO puede agregar todos los elementos que permitirán que el equipo de desarrollo respalde la implementación completa de la funcionalidad, como:

  • Criterios de aceptación o «reglas de negocio».
  • La documentación de wireframes / modelos y otros elementos gráficos de la interfaz de usuario.
  • Los criterios de éxito o los «KPI» que se deben seguir para medir el valor de la historia de usuario
  • Pruebas de aceptación (en formato BDD, por ejemplo: ver BDD y Gherkin) para validar objetiva y sistemáticamente si la historia de usuario se ha implementado correctamente

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *