Historias de usuario: todo lo que querías saber y no te atreviste a preguntar - Versión 1.7 - 20190613

1. 1

2. 2 | Copyright © 2018 Tata Consultancy Services Limited
20190613
Trabajo en Progreso

3. 3
Historias de usuario: una visión pragmática

4. 4
Copyright © 2018, 2019
Jorge Abad, Lucho Salazar
ISBN 978-1-723-93356-1

5. 5

6. 6
Tabla de Contenido

7. 7
1
Historias de
Usuario: un nuevo
orden en los
requisitos
3
Como luce
una historia
de usuario
5
Historias de
usuario altamente
efectivas (INVEST)
2
La magia de
las historias
de usuario
4
Los modos de
representación de
las historias de
usuario
10
The user story
conversation
canvas
8
De historias de
usuario, cultura y el
arte de narrar
historias
6
INVEST ++
9
Algunas ideas
clave sobre las
historias de
usuario
7
Convertir una
épica en una
historia de
usuario

8. 8
Prólogo

9. 9.
Con historias y
contando historias
es como las
culturas se hacen
más fuertes y
sobreviven

10. 10.
Las historias generan conexiones entre los emisores y los receptores
y hacen que unos y otros se conviertan en un solo grupo, un solo
equipo, un solo ser

11. 11
Las historias son un
poderoso medio para
fomentar la cooperación
y la enseñanza de
muchas cosas

12. 12
Las historias de usuario permiten
crear un vínculo entre usuarios o
consumidores y desarrolladores
de productos

13. Las historias de usuario permiten a
los equipos virtuosos construir los
productos correctos
Incluso antes de
pensar en
hacerlo de la
manera correcta

14. Nos permiten concentrarnos en el valor de los componentes de cada
producto
y de cómo estos componentes hacen o harán resonancia unos con
otros

15. Nos permiten concentrarnos en el valor de los componentes de cada producto
y de cómo estos componentes hacen o harán resonancia unos con otros

16. Nos permiten concentrarnos en el valor de los componentes de cada producto
y de cómo estos componentes hacen o harán resonancia unos con otros
Las historias de usuario son el primer movimiento de
esa sinfonía que es el descubrimiento del producto y
de sus características

17. Nos permiten concentrarnos en el valor de los componentes de cada producto
y de cómo estos componentes hacen o harán resonancia unos con otros
Las Historias de
Usuario nos ayudan
a entender la
proposición de valor
del producto desde
sus inicios

18. Nos ayudan a
anticiparnos a la
gran incógnita
que supone si los
usuarios usarán
o no el
producto

19. Historias de Usuario: un nuevo
orden en los requisitos

20. La historia de usuario es un sustituto más ligero para lo que han sido
nuestros medios tradicionales de especificar requisitos de software
¡Las historias de usuario no son
requisitos de software!

21. Historia de
Usuario
Requisito
(de software)
Desarrollador

22. * dejan un legado,
HERENCIA
* Porque son simples,
SIMPLICIDAD
* trascienden más allá del
tiempo (y del espacio),
TRASCENDENCIA
* permiten que las culturas
sobrevivan
SUPERVIVIENCIA
02
03
04
01

23. 2 31
* Fáciles de entender
y de aceptar
FACILIDAD
* De franca
recordación
PERSISTENTES
* Descripción
corta
BREVES

24. Quiero conocer
qué actividad hay
en mi blog
HISTORIA 4
Quiero ordenar
las entradas al
blog por fecha
HISTORIA 3
Quiero buscar
temas en el blog
HISTORIA 2
Quiero publicar
en el blog
HISTORIA 1
Una Historia de Usuario es una breve declaración de intención que
describe algo que el sistema necesita hacer para el usuario
Una historia de usuario es una carta de intención

25. Una historia de usuario es un recordatorio de una conversación
(a tener en el futuro)

26. Una historia de
usuario es un
recordatorio de una
conversación
(a tener en el futuro)

27. Representan incrementos pequeños de funcionalidad
valorada que puede ser desarrollada en pocos días
2
Son cortas y fáciles de leer, entendibles por los
desarrolladores, interesados y usuarios
1
Fáciles de estimar porque el esfuerzo de implementar la
funcionalidad puede determinarse rápidamente
3
No se llevan en documentos grandes o pesados, sino en
listas organizadas que se reordenan fácilmente
4

28. Evitan especificidad demasiado pronto, retardos en el
desarrollo e inventario de requisitos
6
No se detallan al principio del proyecto, sino que se
elaboran sobre una base JIT (just-in-time)
5
Necesitan poco o ningún mantenimiento y se pueden
desechar con seguridad después de la implementación
7
Sirven como insumo para la documentación, la cual
también es elaborada de manera incremental
8

29. Por lo general, representan “funcionalidades parciales”
de valor, es decir, no indican funciones o
procedimientos complejos y grandes que el sistema
debe hacer
*

30. La Magia de las Historias de
Usuario

31. y en la
Planificación, el
equipo
pregunta al
Dueño de
producto el
detalle de lo
que quiere y lo
que espera.
Durante el
refinamiento
En la
planificación,
con base en lo
conversado, el
equipo estima lo
que va a construir
en presencia del
Dueño de
producto
&
01
Durante del
Sprint,
el equipo clarifica
con el Dueño de
producto detalles
menores olvidados
(
02
Criterios de
aceptación,
¡Esto es lo que nos
tiene maravillados!
a
03
La simpleza de las Historias de Usuario obliga al equipo
a estar en comunicación con el Dueño de producto

32. 04
Aceptación
03
Despliegue
02
Condiciones
01
Funciones
Cumplir los
aspectos
funcionales,
Cumplir con
los criterios de
aceptación y
de pruebas (ya
sean estas
manuales o
automatizadas
Desplegado y
funcionando
en un
ambiente
determinado
Fue probada y
certificada por
el equipo +
Fue aceptada
por el Dueño
de Producto
Una historia de usuario no estará finalizada hasta
que cumpla todos sus escenarios y cumpla todos
los criterios de Terminado

33. v
r h
e o
Estamos orientados
al resultado
y no a la
especificación
No quedan escenarios
sin probar,
pues estos se
explican en los
criterios de
aceptación
Lo que está por fuera
de los criterios de
aceptación se
convierte en una
nueva historia
y se le asigna
prioridad
Se puede olvidar
no nos tenemos que
volver a preocupar por
ella pues el desarrollo
orientado a casos de
prueba garantizará que
no quedaron escenarios
por cubrir
Las grandes ventajas que hemos visto son

34. Cómo Luce una Historia de
Usuario

35. Sincronizar las expectativas
del Dueño de Producto o
usuario con el equipo
respecto a una funcionalidad
Servir como elemento que
dirigirá la elaboración del
producto (de software)

36. Lo importante de la historia es la
conversación que se genera o se
debe producir alrededor de la
misma

37. La forma y el
utensilio que se use
para documentarlas
pierden valor,
sobre todo ante
el consabido
principio de la
conversación
cara a cara y el
valor de la
confianza en
Scrum

38. Los Modos de Representación
de las Historias de Usuario

45. …

46. …

48. …

49. Historias de Usuario altamente
efectivas

50. Independiente
No requiere de otra
Negociable
Se puede reemplazar por
otra de diferente prioridad
Valuable | de Valor
Necesaria y de valor para el
producto y los consumidores
Estimable
El equipo se siente seguro
al estimar el esfuerzo
requerido
Sucinta | Pequeña
Se puede construir en una
iteración junto a otras historias
Comprobable
Se puede probar y
verificar
I
N
V
E
S
T

51. Sucinta | Pequeña
Se puede construir en una
iteración junto a otras historias
S

52. …

53. Sucinta | Pequeña
Se puede construir en una
iteración junto a otras historias
S
historias de usuario tan pequeñas
que las puedas finalizar durante
las primeras horas o días del
Sprint
Historias de usuario cuyo
tamaño oscile entre 1/10 y 1/6
de la capacidad del equipo, en
cada iteración
historias de usuario con Valor
para el negocio, es decir, no caer
en la descomposición funcional
Historias de usuario que
inviten a una conversación,
ojalá cara a cara, entre
representantes del negocio y el
equipo de producto

54. * Basado en el post
https://agileforall.com/resources/how-to-split-a-user-story/
en el que se propone que las historias deben tener entre 1/10 a 1/6 de la
velocidad del equipo por sprint
** Los números fueron aproximados al entero superior
Basado en la sugerencia de Thomas Wallet (@WalletThomas), en el que me
mostraba que tener historias gigantes no es buena práctica puse la
clasificación amarillo, naranja y roja, mostrando que hay tamaños grandes
de historias de usuario que posiblemente se constituya en unas épicas
susceptibles de ser divididas
El esfuerzo invertido en esta historia es grande, se sugiere hacer partición
de la historia de usuario
El esfuerzo invertido en esta historia de usuario versus la duración del
sprint lo pone en riesgo que se logre en el tiempo comprometido, es un
tamaño de historia riesgoso, se sugiere realizar división de la historia
Definitivamente no se recomiendan historias de usuario de este tamaño ya
sea porque están cerca, iguales o exceden el tamaño del sprint, o porque
su tamaño es lo suficientemente grande y es altamente factible que puedan
ser divididas en historias de usuario más pequeñas

55. * Basado en el post
https://agileforall.com/resources/how-to-split-a-user-story/
en el que se propone que las historias deben tener entre 1/10 a 1/6 de la
velocidad del equipo por sprint
** Los números fueron aproximados al entero superior
Basado en la sugerencia de Thomas Wallet (@WalletThomas), en el que me
mostraba que tener historias gigantes no es buena práctica puse la
clasificación amarillo, naranja y roja, mostrando que hay tamaños grandes
de historias de usuario que posiblemente se constituya en unas épicas
susceptibles de ser divididas
El esfuerzo invertido en esta historia es grande, se sugiere hacer partición
de la historia de usuario
El esfuerzo invertido en esta historia de usuario versus la duración del
sprint lo pone en riesgo que se logre en el tiempo comprometido, es un
tamaño de historia riesgoso, se sugiere realizar división de la historia
Definitivamente no se recomiendan historias de usuario de este tamaño ya
sea porque están cerca, iguales o exceden el tamaño del sprint, o porque
su tamaño es lo suficientemente grande y es altamente factible que puedan
ser divididas en historias de usuario más pequeñas

56. …

57. No retrases los requisitos no
funcionales
No dividas demasiado
pronto
No dividas más de la
cuenta
No dividas por
componentes
No olvides las pruebas de
la historia de usuario
Advertencia

58. u
I
n
P
Variaciones por navegador
¿Tiene la historia el mismo comportamiento para varios
navegadores de Internet?
Variaciones por interesado
¿Tiene la historia comportamientos distintos para
diferentes interesados o usuarios?
Variaciones por tipo de usuario
¿Tiene la historia un comportamiento similar para
distintos tipos de usuario?
Variaciones por plataforma
¿Tiene la historia el mismo comportamiento para
varias plataformas o infraestructuras tecnológicas,
por ejemplo, dispositivos móviles o servidores?
Otros patrones de
división
Más específicos, más prácticos o derivados de
los anteriores
01
02
03
04

59. x
G
O
e
Retrasa los comportamientos opcionales
¿La historia incluye mucho comportamiento opcional
(por ejemplo, distintas formas de lograr la misma meta)?
Región geográfica
¿Tiene la historia el mismo comportamiento para
usuarios o datos de diferentes regiones geográficas?
Servicios externos
¿Consume la historia servicios externos que
apenas se van a implementar o que ya están
construidos?
Retrasa las condiciones de error
¿La historia incluye comportamiento asociado a
las condiciones de error, es decir, lo que ocurre
con la historia en una situación con errores?
Otros patrones de
división
Más específicos, más prácticos o derivados de
los anteriores
05
06
07
08
V
El mayor valor
¿La historia incluye mucha funcionalidad, pero el 80%
del Valor que proporciona proviene del 20% de la
misma?
09

60. &
a
b
c
d
e
Disfunción 1
La mayoría de tus historias de
usuario llegan a “Terminado”
apenas unas pocas horas antes
de la Revisión del Sprint
Disfunción 2
Historias de usuario que
sobreviven a una o más iteraciones
Disfunción 3
Iteraciones con muy pocas historias
de usuario. Máximo 2 o 3.
Disfunción 4
Algunas partes de la historia de
usuario, o toda, no son negociables
Disfunción 5
Historias de usuario cuya
estimación se estableció por
“decreto” y no por consenso Disfunción 6
Los criterios de aceptación de una
historias de usuario son otras
historias
Seis disfunciones
de un equipo con las historias de usuario

61. Nos vemos pronto
¡Gracias!
@luchosalazarc
20190613
Trabajo en Progreso

62. 64.
El libro que dio origen a la presentación en mi Gazafatonario:
http://bit.ly/librohu
http://www.gazafatonarioit.com/2018/10/historias-de-usuario-una-vision.html

63. #ÁgilEsAlgoQueEres www.gazafatonarioit.com Copyright © 2015- 2017 - Lucho Salazar @luchosalazarc
Acerca de Lucho Consultor, Facilitador en procesos y prácticas ágiles de software.
Coautor del libro Historias de Usuario: una visión pragmática y
autor de los libros "Asuntos de la Ingeniería de Software", Volumen
I y Volumen II. Traductor al español de la guía oficial de Scrum y de
la Guía oficial de Nexus, el exoesqueleto para escalar Scrum.
Traductor del libro Una guía de supervivencia a la adopción y
transformación ágil: trabajando con cultura organizacional, de
Michael Sahota.
Me dedico a habilitar entornos más productivos para equipos de
proyectos y esfuerzos de desarrollo de productos. Actualmente me
desempeño como Enterprise Agile Coach en Tata Consultancy
Services. Mi foco es llevar a los equipos a pensar en Mejoramiento
Continuo a la vez que interactúen como un sistema complejo que
les permita entregar frecuentemente productos de valor para el
negocio mientras se divierten haciéndolo. Soy un apasionado de la
comunicación y dinámicas de grupo y facilitador de equipos y me
gusta trabajar con personas que amen lo que hacen. Tengo un
apetito insaciable por aprender nuevas cosas y mejorar en lo que ya
conozco y practico. Como Agente de Cambio, llevo a los equipos y
organizaciones al siguiente nivel de sostenibilidad en su
transformación, específicamente, en el uso del enfoque ágil para
conducir personas, proyectos y generar productos cuyos
componentes tengan resonancia y sean capaces de modificar el
modus vivendi de quienes los consumen.
@luchosalazarc
lucho.salazar@gmail.com
http://co.linkedin.com/in/luchosalazar
http://www.gazafatonarioit.com

64. #ÁgilEsAlgoQueEres www.gazafatonarioit.com Copyright © 2015- 2017 - Lucho Salazar @luchosalazarc
Acerca de Jorge Ingeniero Civil, Especialista en Desarrollo de Software y Magister en
Informática, con más de 17 años en la industria del software, en la
cual me he desempeñado como Consultor, Gerente de Proyectos,
Experto en Metodologías, Gerente de Calidad, Scrum Master y en
los últimos cuatro años como Agile Coach para equipos y
organizaciones.
Coautor del libro Historias de Usuario: una visión pragmática.
Traductor del libro Una guía de supervivencia a la adopción y
transformación ágil: trabajando con cultura organizacional, de
Michael Sahota.
Apasionado por la agilidad, la gerencia de proyectos, la construcción
de productos de software y por encontrar formas en que los
trabajadores de conocimiento logren resultados asombrosos.
Comparto continuamente mis experiencias en mi blog
www.lecciones-aprendidas.info – uno de los más visitados de
Latinoamérica –, actualmente me desempeño como Regional Agile
Coach en Tata Consultancy Services acompañando a organizaciones
y equipos a lograr altos desempeños empleando Frameworks y
Metodologías Lean-Agile como Scrum, Kanban, Scrumban, SAFe,
Lean Software Development, Management 3.0 entre otros. Soy
miembro activo de la comunidad Ágiles Colombia y Ágiles
Latinoamérica.
Mi propósito como Enterprise Agile Coach es lograr que los equipos
y organizaciones logren resultados sorprendentes generando valor y
alto retorno.
@jorge_abad
jorge.abad@gmail.com
http://www.linkedin.com/in/jorgeabadl/
http://www.lecciones-aprendidas.info

65. Sobre el material utilizado
• Además de las referencias explícitas, esta presentación puede
contener material o ideas de otras personas u organizaciones
que omitimos sin intención.
• Nota: Tratamos de dar crédito a todos, pero si consideras que faltaste porque no te
referenciamos o debemos modificar algo de tu propiedad, por favor, no dudes en
hacérnoslo saber, contactándonos a: lucho.Salazar@gmail.com o a
jorge.abad@gmail.com.

66. Aviso de Copyright
• Eres libre de:
– Compartir- copiar, distribuir y transmitir este trabajo
– Modificar- adaptar el trabajo
• Bajo las siguientes condiciones
– Atribución: debes atribuir el trabajo en la manera especificada por el autor o licenciante (pero de ninguna
manera que sugiera que ellos aprueban su uso del trabajo).
• Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos
morales del autor.
• Para más información ver http://creativecommons.org/licenses/by/3.0/

67. Información de contacto
• Luis Antonio “Lucho” Salazar Caraballo
– lucho.salazar@gmail.com
– @luchosalazarc
• Jorge Hernán Abad Londoño
– jorge.abad@gmail.com
– @jorge_abad