En esta charla, se explora las historias de usuario, como herramienta fundamental en el desarrollo ágil para potenciar significativamente el valor de los productos. A través de ejemplos y casos reales, se desentraña el poder de las historias de usuario para comprender las necesidades del usuario, mejorar la colaboración en el equipo y garantizar la entrega de productos que no solo cumplan, sino que superen las expectativas.

1. en acción
potenciando el valor de los productos
OSCAR CHUI AGUILAR
MARCO AVENDAÑO

2. TU NOMBRE, PAÍS Y PROFESIÓN
Oscar Marco

3. ¿POR QUÉ ESTAMOS AQUÍ?

4. ¿POR QUÉ FALLAN LOS PROYECTOS?
Why Do Projects Fail?
www.proggio.com/blog/why-​
do-​
projects-​
fail/

5. LA NEVERA FAMILIAR
leche
Sara
miel
Juan

6. ¿QUÉ NO ES UNA HISTORIA DE USUARIO?
Documentación excesiva
Tareas técnicas
Defectos o problemas
Actividades operativas

7. ¿QUÉ ES UNA HISTORIA DE USUARIO?
Descripción sencilla de la
característica de un producto escrita
desde la perspectiva del usuario
final
Comprende:
Descripción escrita
Conversaciones
Pruebas

8. EJEMPLOS
Actualización de Bibliotecas de
Seguridad.
Agregar Comentarios a las
Publicaciones de un Blog.
Crear una Funcionalidad de
Búsqueda Avanzada.
Crear un Panel de Administración.
Implementación de Registro
Detallado de Errores.

9. USER-​
CENTRIC
DESIGN

10. LA PERSPECTIVA DEL USUARIO
user research
user personas
user journeys

11. USER RESEARCH
Recopilación de datos sobre las
necesidades, comportamientos y
preferencias
Los datos se utilizan para crear
productos que satisfagan las
necesidades del usuario
Ayuda a las empresas a comprender
a sus usuarios (éxito de cualquier
producto o servicio)

12. PROCESO Y TÉCNICAS
Identificar los
objetivos de la
user research
Definición de las
preguntas de
investigación
Planificando la
investigación
Realizando la
investigación
Analizando los
datos
Comunicando los
resultados
Encuestas y
cuestionarios
Entrevistas
Pruebas de
usabilidad
Pruebas A/B
Análisis y
métricas

13. USER PERSONAS
Herramienta de diseño que ayuda a
los equipos a comprender el público
objetivo de un producto o servicio
Son personajes ficticios creados
para representar a un grupo de
usuarios similares

15. EMPATHY MAPPING
Representación visual del
comportamiento y las experiencias
de un usuario
Ejercicio colaborativo que ayuda a
los equipos a comprender mejor a
sus usuarios

17. JOURNEY MAPPING
Representación visual de los pasos
que sigue un usuario para lograr un
objetivo particular
Capta la experiencia del cliente,
desde el contacto inicial hasta el
resultado
Descripción de los pensamientos,
sentimientos y acciones del cliente
en cada paso de su viaje

19. DISEÑANDO PARA EL USUARIO
Diseño Centrado en el Usuario Design Thinking User Research
Usability Testing Accesibility Mobile-​
first

21. IMPORTANCIA

22. ¿POR QUÉ SON IMPORTANTES?
Enfoque en las Necesidades del
Usuario
Facilita la Comunicación y
Colaboración
Lenguaje Común para los
Stakeholders:
Alineación en Objetivos del
Producto
Mejora la Eficiencia del Desarrollo
Priorización Basada en Valor para
el Usuario
Maximiza el Valor para el Usuario

23. IMPORTANCIA EN EL DESARROLLO ÁGIL
Captura Eficiente de Requisitos del
Usuario
Priorización Basada en Valor
Empresarial
Guía al Equipo de Desarrollo
Entregas Frecuentes de Software
Funcional
Asegura la Satisfacción de las
Necesidades del Usuario

24. RELACIÓN CON EL MANIFIESTO ÁGIL
Individuos e interacciones sobre
procesos y herramientas
Software funcionando sobre
documentación extensiva
Colaboración con el cliente sobre
negociación contractual
Responder al cambio sobre seguir un
plan

25. ESTRUCTURA

26. PERSONA, ACCIÓN Y OBJETIVO
Persona ​ ​
¿Quíen se beneficia?
Acción ​ ​ ¿Qué se requiere?
Objetivo ​ ¿Cuál es el beneficio?
COMO ​ ​ ​ <ROL / PERSONA>
QUIERO ​ ​ ​
<COMPORTAMIENTO>
PARA ​ ​ ​ ​<EL VALOR>

27. DETALLE DE LA ESTRUCTURA
Persona Acción Objetivo
Describe al usuario o
interesado que es el foco
de la historia
Describe la acción
específica que el usuario
o la parte interesada
desea realizar
Describe el beneficio que
proporciona al usuario

28. EJEMPLO VIAJERO
COMO viajero frecuente,
QUIERO buscar vuelos por fecha y
destino
PARA encontrar fácilmente las
mejores opciones para mi viaje

29. EJEMPLO USUARIO DE SOCIAL MEDIA
COMO usuario de redes sociales,
QUIERO compartir publicaciones de
otros usuarios
PARA difundir contenido que
encuentre interesante

30. EJEMPLO COMPRADOR EN LÍNEA
COMO comprador en línea,
QUIERO filtrar productos por precio
PARA encontrar fácilmente artículos
dentro de mi presupuesto

31. CRITERIOS DE
ACEPTACIÓN

32. ¿QUÉ SON LOS CRITERIOS DE ACEPTACIÓN?
Definen lo que el cliente verá para
aprobar el trabajo como completo
Pueden ser redactados como casos
de prueba o algo menos detallado
Es crucial involucrar a todo el equipo
para definirlos

33. EJEMPLO
COMO gerente de ventas,
QUIERO recibir notificaciones por
correo electrónico sobre contratos
próximos a vencer
PARA asegurarme de que los clientes
no se queden sin productos y no se
pierdan ingresos
Correo electrónico de
notificación enviado el día 15 y
30 de cada mes que contiene un
resumen de todos los contratos
que están por vencer
El correo electrónico de
resumen incluye una URL que
contiene todos los contratos por
vencer

34. PROBAR QUE...
Comienza con las palabras "Probar
que..."
Ayuda a que las personas adopten
una mentalidad de prueba desde el
principio
¿qué se probará para asegurar que el
ítem esté "Terminado"?

35. DEMOSTRAR QUE...
Comienza con las palabras
'Demostrar que...'
Hace que las personas piensen en la
revisión y en lo que les gustaría
mostrar a los interesados que
demuestre valor

36. GHERKIN
Given <a precondition>
When <a user action occurs>
Then <an expected result>

37. GHERKIN

38. HISTORIAS DE
USUARIO EFECTIVAS

39. LAS 3 C
Card
Conversation
Confirmation

40. EJEMPLO
Card Conversation Confirmation

41. INVEST

42. EJEMPLO
Historia de Usuario: Integrar con una Plataforma de Pagos

43. ORDENAMIENTO

44. MOSCOW
2 Ranuras
para
Billetes
8
compartimentos
para tarjetas de
crédito
Materiales
muy
resistentes, así
como las
costuras
Piel, como
el principal
material
Un
compartimento
translúcido para
tu DNI
Un
compartimento
transversal
horizontal
Un Color
llamativo en el
interior de las
ranuras de los
Billetes
Un Color
exterior
Negro
Un
Compartimento
Translúcido
para fotos de la
familia
Monedero
con cierre
Ranura
extra para
el
Pasaporte
Botón a
presión

45. MOSCOW

46. KANO

47. EJEMPLO
LLamadas
mensajes
navegar
camara
fotográfica
duración
batería
varias
aplicaciones
facial
huella
carga
inalámbrica
resistencia
al agua

48. ÉPICAS

49. ÉPICAS
Historias de Usuario que son
demasiado grandes para
implementarlas en un Sprint
Son importantes en un Product
Backlog de amplio alcance
Es necesario dividirlas en historias
más manejables para su atención

50. SPLIT
Épica
H
i
s
t
o
r
i
a
H
i
s
t
o
r
i
a
H
i
s
t
o
r
i
a
H
i
s
t
o
r
i
a
Épica
H
i
s
t
o
r
i
a
H
i
s
t
o
r
i
a
H
i
s
t
o
r
i
a
H
i
s
t
o
r
i
a
presentación
persistencia
negocio

51. CRITERIOS DE ACEPTACIÓN
COMO vacacionista
QUIERO cancelar una
reserva
PARA ajustar mis planes
Probar que un miembro premium
pueda cancelar el mismo día sin
cargo
Probar que a un miembro no premium
se le cobra el 10% por una
cancelación de algún día
COMO miembro premium
QUIERO cancelar una reserva
hasta el último minuto
PARA tener absoluta flexibilidad
COMO miembro no premium
QUIERO cancelar una reserva
hasta 24 horas de antelación
PARA tene flexibilidad

52. ESTIMACIÓN

53. VIAJE
estimar el tiempo
que tomará llegar al
destino
carreteras sinuosas y
cambios de elevación
recoger a un compañero de
viaje
factores inesperados

54. ¿POR QUÉ ES IMPORTANTE ESTIMAR?
Permite entender el alcance
Facilita la planificación y asignación
eficiente de recursos
Ayuda a determinar la cantidad de
esfuerzo para realizar su entrega
Permite identificar riesgos en el
producto y gestionarlos de manera
efectiva

55. ESTIMACIÓN DEL ESFUERZO
Story points
Ideal days

56. STORY POINTS
1 2 3 5 8 13

57. FACTORES A CONSIDERAR EN LA ESTIMACIÓN
Complejidad
Dependencia
Riesgos

58. EJEMPLO
Explicación
Votación
Acuerdo
Estimación

59. PRODUCT BACKLOG

60. FRAMEWORK SCRUM

61. ITEMS DEL PRODUCT BACKLOG
Feature Requests
Cualquier solicitud de
una parte interesada
Nonfunctional
Requirements
Cualidades del sistema
Experiments
Funcionalidad que se
lanza a producción para
probar el mercado
Bugs/Defects
Problemas que han
surgido de una versión
anterior
Use Cases
Lista de acciones entre
un actor y un sistema
Capabilities
Diferentes formas o
canales para acceder a
la funcionalidad
existente
User Stories
Recordatorios para
conversaciones
Enablers
Spikes

62. REQUERIMIENTOS NO FUNCIONALES
Usability
Scalability
Portability
Maintainability
Availability
Accessibility
Supportability
Security
Performance
Cost
Legal and Compliance
Cultural

63. CAPTURA DE REQUERIMIENTOS NO FUNCIONALES
Como un item
Como criterio de
aceptación
Como parte de la DoD
COMO persona invidente
QUIERO instrucciones audibles
PARA usar el ATM por mi propia
cuenta
Probar que el inicio de sesión se
realiza en dos segundos
Probar que la contraseña está
enmascarada
Todas las páginas deben
cargarse en tres segundos
El contenido debe aparecer
tanto en inglés como en
castellano

64. SPIKES
Es un ítem de investigación del
Product Backlog
Su objetivo es aprender más sobre lo
que se necesita para completar una
funcionalidad solicitada
Se justifica: descargar e instale una API
candidata de terceros para ver si
satisface las necesidades de rendimiento
No se justifica: Investigar una
característica para que los Developers
puedan sentirse más seguro con sus
estimaciones

65. ENABLERS
Representan el trabajo necesario
para crear o mejorar la
infraestructura, el marco técnico o
cualquier otro componente que
permita o "habilite" la
implementación de características
específicas del producto
Salud técnica
Preparación para el futuro
Mitigación de riesgos técnicos
Eficiencia del desarrollo
Falta de valor Inmediato
Equilibrio con Historias de Usuario
Decisiones no basadas en evidencia

66. RECOMENDACIONES

67. USUARIOS Y CONVERSACIÓN
Centrado en el usuario Inicio de conversación
Tienen que ver con las necesidades y
objetivos del usuario
Mantener al usuario en el centro de
atención mientras se escribe una
historia de usuario
No se debe pretender que sean
especificación detallada sino más
bien un inicio de conversación
Usarlas para iniciar una conversación
entre el equipo y el usuario
Perfeccionarlas en función de la
retroalimentación

68. SIMPLE
Mantenerlo simple
El formato no lo es todo
pero ayuda
Debe ser breve, simple y fácil de
entender
No se debe incluir jerga técnica ni
detalles innecesarios
El formato "Como [persona], quiero
[acción], para [objetivo]", puede
ayudar a garantizar la coherencia en
todas las historias de usuarios

69. INDEPENDIENTE Y ORDENADAS
Mantenerlas
independientes
Ordenarlas
Deben ser independientes entre sí, lo
que significa que no deben depender
de otras historias para completarse
Esto facilita el ordenamiento y
programación, garantizando que el
equipo de desarrollo pueda trabajar
en ellas en cualquier orden
Ordene las historias de usuarios en
función de las necesidades del
usuario y el valor que aportan al
producto

70. HISTORIAS DE
USUARIO EN EL
DESARROLLO DE
PRODUCTOS

71. GUÍA
PRODUCT
VISION
PRODUCT
STRATEGY
PRODUCT
ROADMAP
PRODUCT
BACKLOG
https://www.romanpichler.com/blog/my-​
product-​
strategy-​
model/
¿Cuál es el propósito del
producto, el cambio
positivo que debe
provocar?
¿Cuál es su enfoque para
hacer realidad la visión y
hacer que el producto sea
exitoso?
(necesidades, mercado,
características,
destacadas, objetivos de
negocio)
¿Cómo implementará la
estrategia durante los
próximos 12 meses?
(objetivos del producto,
fechas o plazos, épicas,
métricas)
¿Qué diseño y
características de UX se
requieren para lograr el
próximo objetivo del
producto?
(épicas, historias de
usuarios, diagramas de
flujo, mockups)

72. GUÍA
PRODUCT
VISION
PRODUCT
STRATEGY
PRODUCT
ROADMAP
PRODUCT
BACKLOG

73. BIBLIOGRAFÍA

74. CONTACTANOS
Oscar Chui Aguilar Marco Avendaño
oaguilarsis@gmail.com
www.linkedin.com/in/oscaralfredochuiaguilar
marcoviaweb@gmail.com
www.linkedin.com/in/oscaralfredochuiaguilar