Algunas veces recibimos proyectos con largas listas donde se describe a detalle todo lo que el producto hará, sin que tengamos visibilidad de por qué cada requerimiento es relevante para las personas que lo usarán - al final del cuento, para quien diseñamos. ¿Te ha pasado? Las historias de usuario son una manera amigable y casual de describir las funcionalidades de un producto o plataforma, que además están plasmadas en lenguaje natural. Su importancia al diseñar un producto centrado en el usuario, y basado en empatía hacia este a través de nuestras Personas, radica en que éstas están narradas desde su perspectiva. En esta plática, conversaremos sobre el origen de las historias de usuario, modelos comunes, y ejercicios prácticos que podrás facilitar con los involucrados de tu proyecto para crearlas. Finalmente, se considerarán también sus debilidades para contemplar en qué casos nos serán más útiles y en cuáles deberíamos pensar en otro formato. Rodrigo Partida Zermeño, en Wizeline. Maestro en Ciencias de Factores Humanos en el Diseño de Información. Se especializa en investigación de usuario y ha facilitado talleres para varios clientes Fortune 500, así como impartido cursos y ejercicios para Wizeline Academy y universidades como Tec de Monterrey.

1. www.productschool.com
Part-time online Product Management Training Courses
and Corporate Training

2. Unete con
35,000+Product
Managers en
Recursos Gratuitos
Descubre buenas
oportunidades
Portal de empleo
prdct.school/PSJobPortalprdct.school/events-slack

3. Egresados de
17 campuses
Ciudades mundialmente
+100
10,000+
Cursos en línea!

4. CERTIFICATES
Your Product Management Certificate Path
Product Leadership
Certificate™
Full Stack Product
Management Certificate™
Product Management
Certificate™
20 HOURS40 HOURS40 HOURS

5. C O U R S E S
Corporate
Training
Level up your team’s product
management skills

6. Historias de Usuario
Por Rodrigo Partida Zermeño

7. Acerca de mí
Rodrigo Partida
Senior UX Manager

8. Agenda
● Orígenes
● Qué son las historias de usuario
● Beneficios
● Limitantes
● Historias de usuario vs...
● User Story Mapping
● Criterios de aceptación

9. Agile

10. Orígenes

11. Alistair Cockburn
● 1998 - Alistair participó en C3, un
proyecto de Chrysler para centralizar
diferentes aplicaciones de pagos de
nómina en una sola
● Ahí acuñó el término: Historias de
Usuario
● Inmediatamente se volvieron parte
de la metodología de Extreme
Programming
● Desde entonces son una
herramienta común en desarrollos
de productos digitales

14. “Una historia de usuario es la
unidad de trabajo más pequeña
en una metodología ágil.
Es un objetivo final expresado
desde la perspectiva del usuario.”
Max Rehkopf (Atlassian)

15. Iniciativas
Largo plazo
Impacto en alto nivel de la organización
Basadas en objetivos y resultados
Concretas
Son el tema de hoy así que no spoilers
Épicas Épicas
Historias Historias Historias Historias
Las unidades más pequeñas que agregan
valor al usuario.

16. Iniciativas
“Aumentar el número de usuarios que
llegan al sitio de manera orgánica”
“Posibilitar a usuarios la distribución de su
propio contenido.”
“Como un escritor independiente, quiero poder revisar
la ortografía de mi texto en la misma plataforma que lo
publico, para así tener confianza en la calidad de mis
artículos.”
Épicas Épicas
Historias Historias Historias Historias

17. Formato
Como un/una <rol>, puedo <capacidad>
para así <beneficio>.
http://www.agileadvice.com/2014/03/06/referenceinformation/user-stories-and-story-splitting/ USER STORIES AND STORY SPLITTING

18. Hagamos un ejemplo
Como un/una astronauta , puedo
resistir el cambio gravitacional
para así llegar a otra galaxia .
http://www.agileadvice.com/2014/03/06/referenceinformation/user-stories-and-story-splitting/ USER STORIES AND STORY SPLITTING

19. Características
Describen incrementos
funcionales.
Cada historia resulta en valor
al usuario.
https://www.agilealliance.org/ Glossary: User Stories
Para hacer las suposiciones
tangibles, deben presentarse
en una forma física.
Evitan referencias a elementos
técnicos. Se enfocan en
objetivos de los usuarios y en
su vocabulario.

20. Formato
Como un/una <rol>, puedo <capacidad>
para así <recibir beneficio>.
http://www.agileadvice.com/2014/03/06/referenceinformation/user-stories-and-story-splitting/ USER STORIES AND STORY SPLITTING

21. contador

24. Reducir tiempo de carga a 5 segundos.
Buscar carpetas por fecha.
Como un encargado de seguridad la noche antes de que todos se vayan de
vacaciones, quiero crear registro de todos los que ya salieron para poder cerrar
los rehiletes y apagar el sistema sin bloquear a nadie.
Mostrar carrito de compra para verificar lo que se ha agregado.
Cuando estoy por cerrar un reporte, quiero asegurarme de que resolví todos los
comentarios para que los demás miembros de mi equipo sepan que se ha
concluido sin necesidad de entrar en él.
1
2
3
4
5

25. Una buena historia de usuario
✓Incluir usuario o rol ✓Incluir objetivo
✓Razón / Motivación ✓Perspectiva del usuario

26. Una mala historia de usuario
X El rol es alguien del equipo
“Como desarrollador quiero crear un repo de Github
para que mi proyecto tenga dónde vivir.”
X Basar la historia de usuario en funcionalidad
“Como administrador quiero introducir mi contraseña
para hacer log in.”
X Describir el rol como “usuario”
“Como usuario quiero ver el desglose de datos para así
conocer cómo se calcularon las conclusiones.”

27. Beneficios
● Atacamos una necesidad de manera constructiva
● Puedes ver tu producto desde otra perspectiva
● Se detectan nuevas fubncionalidades al pensar en los
objetivos
● Poder organizar los releases

28. Beneficios
● Iniciadores de discusión
● Priorizan implementaciones
● Proveen bases para criterios de éxito
● Promueven separación clara de responsabilidad entre
el product owner (el qué) y el equipo que ejecuta (el
cómo)
● Proveen a la persona que se beneficiará de las tareas
y especifican su valor
● Mantienen al producto centrado en el usuario
https://www.agilealliance.org/ Glossary: User Stories
https://www.atlassian.com/agile/project-management/user-stories

29. Limitaciones
● No puede aplicar una historia para todos los usuarios
● Las historias deben ser independientes
●

30. Limitaciones
● No profundizan en requerimientos técnicos ni diseño
visual
● La cláusula final “para así” muy seguido es omitida.
● Sin embargo, ahí está lo mero mero.
● Aún así, escribirlas completas siempre, puede ser
tedioso.
● Pueden dar una falsa sensación de conocimiento, si no
están basadas en investigación.
● Al ocupar un área grande y estar conformadas por
tarjetas fáciles de desordenar, puede ser riesgoso con
equipos remotos.
https://www.smartsheet.com/user-story-templates

31. User
Stories
versus

32. User
Stories
versus
Un caso de uso es una descripción
de cómo los usuarios van a hacer
una tarea. Resalta el comportamiento
del sistema conforme responde a las
interacciones.
Use Cases
Los miércoles la mucama reporta a la
lavandería. Organiza la ropa que ha
llegado. Introduce el número de
prendas en el kiosko digital. Después
presiona el botón de iniciar y un
temporizador le indica cuánto tardará
el proceso.https://www.usability.gov/how-to-and-tools/methods/use-cases.html

33. User
Stories
versus
No equivalentes a las historias de
usuario, pero comúnmente
intercambiados. Mencionan acciones
específicas pero sin persona ni
objetivos.
Tareas
Enviar mensaje privado.
Cerrar sesión.

34. Épicas Épicas
Historias Historias Historias Historias
Tareas Tareas Tareas Tareas Tareas Tareas Tareas Tareas

35. User
Stories
versus
Waterfall. Los requerimientos
muestran con detalles específicos, y
técnicos, cómo la plataforma debe
comportarse. Su propósito es guiar al
equipo de desarrollo.
Requerimientos
El usuario podrá resetear su
contraseña una vez que haya
recibido el correo con su
autorización. El correo debe contener
un enlace único que expirará en dos
horas.
https://blog.aha.io/user-stories-vs-product-requirements/

36. User
Stories
versus
Una feature es una unidad de
funcionalidad que satisface un
requerimiento.
Features
Registro de usuario.
Log in.
Mostrar carrito de compra.
Agregar productos al carrito.
http://www.jot.fm/issues/issue_2009_07/column5/

37. Job Stories?
Por Leonardo DiCaprio.
Ahhh te creas haha XD
Alan Klement.

38. User
Stories
versus
Basado en Jobs to be done
(jtbd.info).
Las Job Stories analizan situaciones
y motivaciones. No al usuario.
Buscan reemplazar las user stories.
No admiten suposiciones: Deben
estar basadas en investigación
empírica.
Job Stories
https://uxdesign.cc/better-stories-with-job-story-3467de354f45

39. Una vil suposición.
Como un/una <rol>, puedo <capacidad>
para así <recibir beneficio>.
https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27

40. Cuando <Situación> quiero <Motivación>, y así
podré <Resultado>.
https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27
Formato: Job Stories

41. Cuando estoy por cerrar un reporte, quiero
asegurarme de que resolví todos los comentarios
para que los demás miembros de mi equipo sepan
que se ha concluido sin necesidad de entrar en él.
Job Stories: Ejemplo

42. Dos consejos para buenas Job Stories
Cuando <Situación> quiero <Motivación>, y así
podré <Resultado esperado>.
1. Si la “situación” y el “resultado esperado” no son fáciles de escribir
y solamente tenemos clara la “motivación”, entonces
probablemente ésta Job Story no agrega mucho valor y la
podemos omitir.
2. La “motivación” debe ser agnóstica de soluciones.

43. UX es una
disciplina
práctica.

44. UX

45. User
Story
Mapping
por Jeff Patton

46. La creación de las historias
no es tan importante como la
conversación alrededor de
ellas.

48. https://medium.com/@priyank.it/user-story-mapping-product-backlog-creation-7ea9a54f7f0e
Por Priyank Shah

56. “Shared documents
aren't shared
understanding.” Jeff Patton

57. Criterios de aceptación
● Agile.
● Lista de estándares que el
sistema debe cumplir para que
ésta parte del acuerdo se
considere completa.
https://www.testingexcellence.com/difference-acceptance-tests-requirements/

58. Criterios de aceptación
● El título, ID de los comentarios y su fecha son siempre visibles.
● En el preview de la página hay una opción para descargar con
comentarios y otra para imprimir.
● Es posible descargar para archivos .docx, .pdf y .xls.
https://www.yodiz.com/blog/user-stories-acceptance-definition-and-criteria-in-agile-methodologies/
Como un coordinador quiero tener la opción de
imprimir con comentarios incluidos para así tener
un archivo físico de la colaboración.

59. Épicas Épicas
Historias Historias Historias Historias
Tareas Tareas Tareas Tareas Tareas Tareas Tareas Tareas

60. ?

61. Conclusiones
● Las historias de usuario son las piezas en las que se dividen las
épicas/proyectos
● Están conformadas por 3 partes:
○ Rol/Usuario
○ Capacidad
○ Beneficio
● Otro formato bueno son las Job Stories pero éstas sólo pueden
hacerse después de hablar con tus usuarios
○ Situación
○ Motivación
○ Resultado
● Para organizar las historias de usuario, usa User Story Mapping
● Una vez con tus historias, agrega criterios de aceptación para
cada una

62. Agile no se diseñó
para diseño.

63. @ro.part

64. M O R E I N F O
To find out more
about the certificates
visit our website
www.productschool.com
Schedule a call
prdct.school/AdmissionsOr

65. Próximos EVENTOS
Diciembre 12 (jueves)
Como Fuimos de la
Idea a Tener un Head
of Product
Enero 8 y 9 (miér. y jue.)
Ep. 7 y 8: Ideation,
Scenarios y
Storyboards

66. C O M M U N I T Y
https://www.meetup.com/product-school-guadalajara
Let us know what you
thought of our event
prdct.school/EventSurvey

67. http://bit.ly/produkto-whatsapp-gdl