Historias De Usuario

Historia de usuario
Descripción de una funcionalidad que debe incorporar un sistema de software, y cuya implementación 
aporta valor al cliente. 
La estructura de una historia de usuario está formada por: 
●

Nombre breve y descriptivo. 

●

Descripción de la funcionalidad en forma de diálogo o monólogo del usuario describiendo la 
funcionalidad que desea realizar. 

●Criterio de validación y verificación que determinará para considerar terminado y aceptable por 
el cliente el desarrollo de la funcionalidad descrita. 

Y adicionalmente por la información que resulte necesaria por el modelo de implementación: Prioridad, 
Riesgo, Tamaño, etc. 
Estructura: 
• ID – un identificador único, simplemente un número auto­incremental. Esto nos permite no perder la pista a las historias cuando cambiamos su nombre.  
• Nombre – una descripción corta de la historia. Por ejemplo, “Ver tu historial de transacciones”. 
Suficientemente claro como para que el Dueño de Producto comprenda aproximadamente de qué estamos  
hablando, y suficientemente clara como para distinguirla de las otras historias. Normalmente, 2 a 10 
palabras. • Importancia – el ratio de importancia que el Dueño de Producto da a esta historia. Por ejemplo, 10. O 150. 
Más alto = más importante. Suelo evitar el término “prioridad” porque típicamente “1” se considera la  
“máxima prioridad, lo que es muy incómodo si posteriormente decides que algo es más importante. ¿Qué 
prioridad le daríamos a ese nuevo elemento? ¿Prioridad 0? ¿Prioridad ­1?  • Estimación inicial – la valoración inicial del Equipo acerca de cuanto trabajo es necesario para 
implementar la historia, comparada con otras historias. La unidad son “puntos de historia” y usualmente 
corresponde a “días­persona ideales”. Pregunta al Equipo: “si tuvierais el número óptimo de personas para 
esta historia (ni muchos ni pocos, típicamente 2) y os encerraseis en una habitación con cantidad de comida, y trabajaseis sin distracciones, ¿en cuantos días saldríais con una implementación terminada, 

demostrable, testeada y liberable?”. Si la respuesta es “con 3 tíos encerrados en una habitación nos llevaría 
4 días”, entonces la estimación inicial son 12 puntos. Lo importante no es que las estimaciones absolutas 
sean correctas (es decir, que una historia de 2 puntos deba durar 2 días), lo importante es que las estimaciones relativas sean correctas (es decir, que una historia de 2 puntos debería durar la mitad que una 
historia de 4 puntos).  
• Como probarlo – una descripción a alto nivel de como se demostrará esta historia en la Demo al final del 
Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, 
entonces debería ocurrir aquello”. Si practicáis TDD (Test­Driven Development, desarrollo orientado a test) esta descripción puede usarse como pseudo­código para vuestro test de aceptación.  
• Notas – cualquier otra información, clarificación, referencia a otras fuentes de información, etc. 
Normalmente muy breve. 
 
Ejemplos: 
 

 
Ejemplo de historia de usuario 

 

 
Ejemplo de historia de usuario 
 

 
 
 
 
http://www.scrummanager.net/bok/index.php?title=Historia_de_usuario ¿Cómo decide el usuario que historia(s) incluir en el Sprint? 
 
Se utilizan 2 técnicas: 
1.­ A ojo de buen cubero 
2.­ Cálculos de velocidad 
 
Estimación a ojo de buen cubero 

 
 
Estimando usando cálculos de velocidad 
 
Esta técnica consta de dos pasos  
 
1. Decidir la velocidad estimada 
 
2. Calcular cuántas historias se pueden añadir sin sobrepasar la velocidad La velocidad es una medida de “cantidad de trabajo realizado”, donde cada elemento se evalúa en función de 
su estimación inicial.  
 
velocidad estimada al principio de un Sprint y la velocidad real al final de dicho Sprint. Cada 
rectángulo es una historia, y el número interior es la estimación inicial de dicha historia. 
 

 

Cálculo de la velocidad estimada: 
 ...