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.
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.
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
14.
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
16.
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
18.
19. DISEÑANDO PARA EL USUARIO
Diseño Centrado en el Usuario Design Thinking User Research
Usability Testing Accesibility Mobile-
first
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
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
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
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
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
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
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
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
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
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
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)