Representan una funcionalidad mínima que aporta valor para el negocio. Lo ideal es que tarde entre 2 y 3 días de desarrollo para ser completada. Si es muy grande la llamamos Épica y la desglosamos en varias historias de usuario.
Son un recordatorio de qué hay que hacer para que el equipo determine cómo hacerlo. El objetivo de usarlas es el entendimiento compartido. Se ordenan en el Product Backlog.
Las 3 C
Las HU tienen tres partes:
- Card: la tarjeta es el medio físico. Incluye la descripción de la funcionalidad.
- Conversación: incentiva la discusión para generar un entendimiento compartido del requerimiento. Se busca lograr la colaboración con el cliente por sobre la documentación.
- Confirmación: son los criterios de aceptación. Incluye pruebas para la validación de su completitud. El testing pasa de ser una etapa del desarrollo a una actividad.
Formato
Las HU se escriben desde el punto de vista del usuario que necesita la funcionalidad. Dicen el qué, NO el cómo.
[Título]
Como [rol]
quiero hacer [funcionalidad]
con el objetivo de [beneficio]
Aclarar el rol ayuda a identificar y diferenciar los permisos de los distintos roles del sistema. En la industria y algunos autores omiten el título y el beneficio.
Criterios de Aceptación
Se pueden escribir en lenguaje Gherkin:
Scenario
Given [context]
When [event]
Then [result]
Además pueden incluir restricciones no funcionales asociadas al requisito de la HU.
Alcance
Tema > Épicas > Historias de Usuario > Tareas.
Los temas son aspectos enormes del sistema e inicialmente no es claro que HUs contienen.
Las tareas son el “cómo hacerlo” y las escribe el equipo de desarrollo con certidumbre.
Redacción de Historias de Usuario
Es importante escribir buenas historias de usuario.
Método INVEST
Comprueba (NO asegura) la calidad. La HU debe reunir estas características:
- Independent: se busca minimizar las dependencias. Difícil de lograr en la realidad.
- Negotiable: debe ser discutible con el cliente.
- Valuable: aportar valor.
- Estimable: poder planear.
- Small: pequeña.
- Testeable: se tiene que poder probar.
Tips de Mike Cohn
- Empezar por historias objetivo: ¿qué necesita hacer el usuario?
- Cortar la torta: dividir historias verticalmente en funcionalidades mínimas end-to-end.
- Escribir historias cerradas: el usuario logra un objetivo al terminarlas.
- Poner restricciones en las tarjetas: requisitos no funcionales.
- Tamaño en base al horizonte: detallar las más cercanas.
- Mantener la UI lo más lejos posible: funcionalidad > interfaz.
- Algunas cosas no son HU: por ejemplo la paleta de colores.
- Incluir el rol del usuario: aclara permisos.
- Escribir para un rol individual: pensar en un usuario específico.
- Escribir en voz activa: mayor claridad.
- El cliente escribe: lo obliga a pensar qué quiere.
- No numerar las tarjetas: hablar de features, no números.
- No olvidar el propósito: son un recordatorio de discutir la funcionalidad.
Bad Smells de Mike Cohn
Indicadores de una mala historia de usuario:
- Historias demasiado pequeñas: dificulta la estimación.
- Historias interdependientes: dificulta la planificación.
- Goldplating: generarle necesidades al cliente que no tiene.
- Demasiados detalles.
- Detalles de interfaz muy tempranos.
- Pensando demasiado adelante.
- Separando demasiadas historias.
- Al cliente se le dificulta la priorización.
- El cliente no quiere escribir o priorizar las historias.