Cómo reportar nuevos requerimientos (Historias de Usuario y Job Stories)

Aunque existen diferentes métodos para comunicar los requerimientos o ideas a los diferentes equipos de trabajo, sobre todo al equipo de desarrollo, en este artículo nos vamos a centrar en dos: Historias de Usuario (HU) e Historias de Trabajo (Jobs Stories). Ambas tienen un objetivo común: definir claramente las necesidades del usuario para orientar al equipo de desarrollo en la creación de soluciones efectivas. Ambos métodos buscan comunicar el contexto y el propósito detrás de cada requerimiento, asegurando que el equipo comprenda qué problema están resolviendo y por qué es importante para el usuario. Esto permite desarrollar características que realmente agreguen valor y mejoren la experiencia del usuario.

Aunque la intención es la misma, se considera que las Job Stories entregan más contexto en comparación con las Historias de Usuario ya que ayuda a comprender cuando y por qué surge la necesidad, lo cual puede guiar al equipo de desarrollo a producir soluciones más precisas y alineadas con el comportamiento del usuario.

Sintaxis

Sintaxis

Ejemplos

Job Stories

Cuando “situación o evento”, quiero “alguna meta o motivación” para “alguna razón o resultado previsto”.

(se enfocan en la situación, la meta y la razón para lograr esa meta)

Cuando estoy creando un nuevo cliente, quiero que se me listen los que ya tengo registrados para evitar duplicados y dificultar el análisis de clientes.
Cuando manejo consultas de clientes, quiero acceder al historial de sus pedidos recientes para comprender mejor sus necesidades.

Historia de Usuario

Como “tipo de usuario”, quiero “alguna meta” para “alguna razón”.

(se centran en el usuario, su objetivo y la razón detrás de ese objetivo)

Como cliente, quiero poder rastrear mis pedidos para saber cuándo llegarán.
Como usuario administrador, quiero poder exportar un archivo para monitorear la actividad de los usuarios para tomar mejores decisiones.

Criterios de aceptación

Hasta aquí sabemos cómo escribir el contexto de las historias y las Job Stories, pero falta algo muy importante: el detalle de cómo vamos a satisfacer las necesidades de los usuarios; para eso escribimos los criterios de aceptación.

Ayuda al equipo de desarrollo y grupos de interés (directores, gerentes de producto, clientes entre otros) a entender lo que se va a desarrollar para marcar la historia como “hecha”.
Ayuda al equipo de QA y QC a hacer su trabajo porque utilizar los criterios de aceptación para confirmar si lo que se ha desarrollado está funcionando como esperaba (una reunión menos).
También ayuda a la planeación del equipo porque ayuda a determinar el esfuerzo de lo que se va a entregar y su estimación de tiempos.

Ejemplo de una Job Story con criterios de aceptación

Cuando soy un agente de logística que coordina envíos internacionales, quiero recibir notificaciones automáticas cuando un contenedor cambie de ubicación para asegurarme de que los envíos se están moviendo según lo planeado.

Criterios de Aceptación:

Se debe poder configurar las preferencias de notificación para elegir el tipo de cambio de ubicación del contenedor que deseo recibir (ejemplo: cambio de puerto, cambio de país).
Cuando un contenedor cambie de ubicación según mis preferencias, debo recibir una notificación instantánea en la aplicación y por correo electrónico.
La notificación debe incluir detalles precisos sobre el contenedor, como el número de identificación, la nueva ubicación y la fecha/hora del cambio.
Debe existir un registro histórico dentro de la aplicación que muestre los cambios de ubicación anteriores de cada contenedor para referencia futura.
Las notificaciones deben ser precisas y enviarse en tiempo real, sin retrasos significativos.

Estos criterios de aceptación detallan los requisitos específicos que deben cumplirse para satisfacer la necesidad del agente de logística en cuanto a recibir notificaciones sobre los cambios de ubicación de los contenedores en el software de seguimiento de contenedores.

Consejos

Las Job Stories pueden incluir el usuario o rol cuando sea necesario (ejemplo: cuando los “agentes de carga” quieren…)
Mientras más contexto mejor la solución, pero siendo claros y concisos. Es importante reforzar el “cuando” de las Job Stories.
Lo que motiva a los clientes incentiva el uso de los productos y servicios, por eso es importante la parte de “alguna meta o motivación”.
Son negociables porque no restringen a como se resuelve el problema del usuario, para eso son los criterios de aceptación que explican a continuación.

Conclusiones

Una redacción clara y precisa de los requerimientos de usuarios, usando Job Stories o Historias de usuario, con sus respectivos criterios de aceptación garantiza:

Comprensión clara: Todos comprenden qué se espera del producto.
Enfoque en el usuario: Se centra en las necesidades del usuario.
Cumplimiento de expectativas: Asegura que el producto satisfaga las expectativas.
Reducción de reuniones innecesarias: Evita discusiones y confusiones, eliminando pérdida de tiempo.
Menos ambigüedad: Minimiza malentendidos y ambigüedades, reduciendo la necesidad de chats o reuniones adicionales.

En resumen, una redacción clara y precisa no solo garantiza un mejor enfoque y cumplimiento del producto, sino que también minimiza pérdidas de tiempo y ambigüedades en la comunicación.