6. Historias de Usuario

Las historias de usuario conectan necesidades reales con el trabajo del equipo. Son conversaciones estructuradas que capturan el valor, facilitan la colaboración y mantienen el foco en la experiencia del usuario final.

6.1 Qué son y cómo se escriben

Una historia de usuario describe una funcionalidad desde la perspectiva de la persona que obtiene el beneficio. Se redacta de forma breve, orientada al valor y siempre deja espacio para el diálogo entre Product Owner y Developers.

• Empatía: se centra en la motivación de quien usará la funcionalidad, no en los detalles técnicos.
• Conversación: es un recordatorio para discutir; se complementa con notas, diseños o criterios de aceptación.
• Valor visible: cada historia debe apuntar a un resultado observable para el negocio o el usuario.

6.2 Estructura: Como [rol] quiero [función] para [beneficio]

La plantilla más difundida ayuda a enfocar la necesidad y el resultado esperado. Puede adaptarse según el producto, pero siempre conserva los tres componentes clave.

Al redactar historias, evita tecnicismos innecesarios y valida con usuarios o stakeholders que el enunciado refleja su necesidad.

Ejemplo AgroSmart: el Product Owner trabaja con agrónomos y comerciales para describir la historia «Como agrónomo quiero ver la tendencia de humedad semanal por parcela para ajustar el riego programado», sobre la que refinan datos necesarios y priorizan la integración IoT.

6.3 Criterios de aceptación

Los criterios de aceptación complementan la historia. Detallan las condiciones que deben cumplirse para considerar la funcionalidad terminada según la Definición de Done.

• Claridad: exponen reglas de negocio, restricciones o comportamientos esperados.
• Prueba verificable: sirven como base para pruebas funcionales o automatizadas.
• Negociación: se refinan con el equipo antes del sprint para eliminar ambigüedades.

Scenario: Tendencia semanal de humedad
  Given un agrónomo con sensores activos en una parcela
  When consulta la vista de tendencia de humedad
  Then visualiza la curva de los últimos 7 días con variación porcentual
  And recibe una alerta si el cambio supera el 5%
  And el sistema marca sensores sin datos cuando la desconexión supera 30 minutos

6.4 Estimación de esfuerzo

Scrum recomienda estimar la complejidad relativa de las historias con puntos de historia en lugar de horas directas. El objetivo es comparar trabajo y facilitar la planificación basada en capacidad.

• Puntos de historia: reflejan combinación de esfuerzo, incertidumbre y riesgo.
• Planning Poker: cada persona elige una carta (generalmente serie Fibonacci) y se discuten diferencias hasta converger.
• Velocidad de equipo: la suma de puntos completados por sprint ayuda a proyectar compromisos futuros.

Durante la estimación, los Developers pueden dividir una historia grande en historias más pequeñas o tareas si supera el tamaño aceptable.

6.5 Priorización

El Product Owner ordena las historias de usuario para maximizar el valor entregado. La priorización combina impacto de negocio, urgencia y esfuerzo estimado.

• MoSCoW: clasifica en Must, Should, Could y Won't para alinear expectativas con stakeholders.
• Valor de negocio: usa indicadores como ingresos esperados, reducción de costos o satisfacción del usuario.
• Evidencia: datos de uso, feedback de clientes y resultados de experimentos informan la decisión.

Una historia priorizada se documenta con la información necesaria para ser seleccionada durante la Sprint Planning y evolucionar con el refinamiento continuo.