Una historia de usuario describe una funcionalidad que será de valor para un usuario o comprador de un sistema o software. Las historias de usuario se componen de tres aspectos1:
-
Una descripción escrita de la historia utilizada para la planificación y como recordatorio.
-
Conversaciones sobre la historia que sirven para desarrollar los detalles de la historia.
-
Pruebas que transmiten y documentan detalles y que pueden usarse para determinar cuándo una historia está completa.
Las historias de usuario son una descripción informal y en lenguaje natural de las características de un sistema de software. Están escritas desde la perspectiva del usuario final.
Las historias de usuario se utilizan para crear estimaciones de tiempo2. Las historias de usuario solo deben proporcionar suficientes detalles para hacer una estimación de riesgo razonablemente bajo de cuánto tiempo llevará implementar la historia. Cuando llegue el momento de implementar la historia, los desarrolladores acudirán al cliente y recibirán una descripción detallada de los requerimientos cara a cara.
La estimación temprana es una diferencia clave entre las historias y otras prácticas de requerimientos. La estimación brinda a las perspectivas técnica y de negocio la oportunidad de interactuar, lo que crea valor desde el principio, cuando una idea tiene el mayor potencial. Cuando el equipo conoce el costo de las funciones, puede dividirlas, combinarlas o ampliarlas2.
Cada historia tendrá una estimación de 1, 2 o 3 semanas en el "tiempo de desarrollo ideal". Este tiempo de desarrollo ideal es el tiempo que llevaría implementar la historia en código si no hubiera distracciones ni otras tareas y supieras exactamente qué hacer. Más de 3 semanas significa que debes desglosar más la historia. Menos de 1 semana y estás en un nivel demasiado detallado, combina algunas historias. Aproximadamente 80 historias de usuarios más o menos 20 es un número perfecto para crear un plan de lanzamiento durante la planificación del lanzamiento2.
Algunos sugieren que las historias de usuario tengan cierto formato3:
Como [persona], quiero [característica o funcionalidad] de modo que [razón]
Persona —ver definición— representa el rol o el usuario.
Tip
Contesta las siguientes preguntas sobre la persona:
- ¿Quién es este usuario?
- ¿Qué lo motiva?
- ¿Ejemplo de este usuario?
Lo que el usuario quiere hacer en la historia es lo que asumes que es su objetivo e implica una característica o funcionalidad en el software. La razón —también llamada a veces recompensa— es algo que se puede probar —demostrar— para determinar que el usuario ha alcanzado su objetivo.
Tip
Contesta estas preguntas sobre la recompensa:
- ¿Por qué quieren hacer esto?
- ¿Cuál es el beneficio?
- ¿Cómo sabemos que está funcionando?
La granularidad de una historia está en algún lugar entre un caso de uso de producto y un requerimiento atómico4.
El siguiente ejemplo de historia de usuario está tomado de 4:
El primer paso de un caso de uso de negocio para un banco dice lo siguiente:
El banco quiere evitar que los clientes sobregiren inesperadamente sus cuentas bancarias. La sanción por sobregiros no concertados, si bien es rentable, está provocando disputas con los clientes que afirman que necesitan una mejor forma de controlar sus cuentas.
Una primera historia de usuario para esto sería así:
Como titular de una cuenta bancaria, quiero consultar mi saldo en línea.
La pregunta que nos está faltando hacer sería ¿por qué el titular quiere consultar el saldo?
La historia de usuario revisada luce así:
Como titular de una cuenta bancaria, quiero consultar mi saldo en línea para poder acceder a mi saldo diario las 24 horas del día.
Pero esa no es la verdadera razón: el titular está tratando de evitar un sobregiro; teniendo eso en cuenta, una nueva versión de la historia de usuario podría ser así:
Como titular de una cuenta bancaria, quiero que me informen si se prevé que mi saldo mensual llegue a cero o menos para poder organizar un sobregiro.
Esta historia de usuario se puede escribir usando la plantilla de requerimiento atómico:
| # Historia de usuario | 6.1 | Tipo del requerimiento | Historia de usuario | # Evento/Caso de uso del negocio | 6 |
| Descripción | Como titular de una cuenta bancaria, quiero que me informen si se prevé que mi saldo mensual llegue a cero o menos. | ||||
| Justificación | Para poder organizar un sobregiro. | ||||
| Fuente | Discusión del BUC 6 con representantes del negocio y los desarrolladores. | ||||
| Criterio de ajuste | Balance a fin de mes proyectado = balance el primer día del mes + salario del mes - suma de los débitos del mes. Si el balance al fin de mes es menor o igual a cero enviar una alerta al titular de la cuenta. | ||||
| Satisfacción del cliente | 3 | Insatisfacción del cliente | 5 | ||
| Prioridad | 1 | ||||
| Dependencias | Ninguna | Conflictos | Ninguno. | ||
| Material de soporte | Reglas de sobregiro provistas por los representantes del negocio. | ||||
| Historia | Versión inicial. | ||||
Las historias de usuario pueden ser agrupadas en épicas —epics—, o dicho de otro modo, las épicas de descomponen en historias de usuario. Pueden tener el mismo formato que las historias de usuario aunque con una granularidad mucho menor, o dicho de otro modo, con un alcanza mucho mayor.
Footnotes
-
Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional. ↩
-
Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change, 2nd Edition. Addison-Wesley. ↩ ↩2 ↩3
-
Cowan, A. (2014). Your Best Agile User Story. https://www.alexandercowan.com/best-agile-user-story/ ↩
-
Robertson, S. & Robertson, J. (2012). Mastering the Requirements Process: Getting Requirements Right, 3rd Edition. Addison-Wesley Professional. ↩ ↩2