Al iniciar el desarrollo de un proyecto software el cliente nos pide un producto con muchas características cuya realización podría llevarnos bastante tiempo, además que luego debemos esperar las observaciones de su revisión. ¿No sería más adecuado ir mostrando las funcionalidades principales del sistema de manera temprana para su validación? si nos animamos a proceder de esta manera surge otra interrogante ¿Cómo podríamos establecer esas funcionalidades prioritarias ya que tenemos un “lista de deseos” muy amplia en nuestro Product Backlog?. Ante esta situación se recomienda desarrollar un Producto Mínimo Viable (MVP) en un tiempo relativamente corto que permita mostrar un producto funcional para que el cliente pueda realizar su evaluación. La presentación muestra la técnica User Story Mapping, que consiste en organizar nuestro Product Backlog para lograr los MVP con la participación del Product Owner y los desarrolladores, para que cada uno aporte su visión y se aclaren dudas para lograr una mejor visión del producto.

1. Sesiones de agilismo
Construyendo el
Producto Mínimo Viable con
User Story Mapping
Marco Avendaño
Agile La Paz

2. Expositor
 Marco Avendaño
 Fundador de Agile La Paz
 @agilelapaz
 agilelapaz@gmail.com
 www.facebook.com/agilelapaz/

3. Proyectos

4. ¿Por qué fallan los proyectos?
 Algunas veces porque
simplemente se construye el
producto equivocado.

5. Desarrollo en cascada

6. Los único constante es el cambio

7. Desarrollo ágil

8. Mona Lisa - incremental

9. Mona Lisa - iterativo

10. ¿Qué construir primero?

11. MVP

12. Producto
Mínimo Viable

13. ¿Qué es el MVP?
 Es versión de un nuevo
producto que permita
recolectar, con el menor
esfuerzo posible, la máxima
cantidad de conocimiento
validado sobre los
potenciales clientes.

14. ¿Qué es el MVP?

15. Scrum

16. Componentes

17. Framework

18. Sprint Backlog
¿Cómo se planifica el Sprint
Backlog?

19. Roles y la estimación
Moderador
Estima Coste
Estima Valor

20. User Story
Mapping

21. ¿Qué es el User Story Mapping?
 Herramienta que permite
generar una representación
visual de la sistema
completo.
 Ofrece una vista general de
todas las funcionalidades
que lo componen (the big
picture) de punta a punta.

22. Beneficios
 Priorizar componentes por
valor de negocio.
 Ayuda a delimitar el alcance.
 Identificar entregas
tempranas.
 Detectar dependencias
entre componentes.
 Refuerza el trabajo en
equipo.
 Es una alternativa para un
plan de proyecto.

23. Resumiendo
 Ayuda a dimensionar la pila
del producto (Product
Backlog) en
 Tiempo (Releases)
 Funcionalidades
(Historias de Usuario).
”Recuerda: al final del día, tu trabajo
no es obtener requisitos correctos –
es cambiar el mundo”
Jeff Patton

24. Estructura

25. Descripción de la estructura
 Backbone: Proceso de Negocio.
 The Walking Skeleton: Lo mínimo con lo que el sistema camina.
A veces se asocia al Mínimo Producto Viable (MVP).
 Activities, User Tasks: Actividades.
 User Stories: Historias de usuario.
 Priorización: Valor de Negocio.
 Plan de Versiones, Raleases: Tiempo.

26. Historias de usuario

27. Herramientas

28. storiesonboard.com

29. cardboardit.com

30. featuremap.co

31. Dinámica

32. El juego
 Levantarse de la cama y
salir.

33. Objetivos
 Mostrar los beneficios de la
priorizar tareas.
 Identificar los MVP.
 Establecer la auto
organización de los equipos.

34. Supuestos
 Asumir que se tratan de una
persona:
 Trabaja
 Soltera
 Sin hijos ni mascotas
 Vive solo

35. Paso 1 - Lista de actividades
 Listar las actividades que
hicieron desde que se
despertaron hasta que
llegaron al trabajo.
 De manera individual.
 Cada actividad debe estar en
un Post-it.

36. Paso 2 - Agrupando las actividades
 Reunir las actividades que
tienen un objetivo común.
 Eliminar las actividades
duplicadas.
 Asignarle un título.

37. Paso 3 - Ordenar las actividades
 Ordenar las actividades
secuencialmente.
 Mostrar el avance del
tiempo de izquierda a
derecha.
 El orden debe representar
una historia con inicio y fin.

38. Paso 4 – Priorizar las actividades
 Priorizar las actividades de
arriba hacia abajo.
 Los actividades más
importantes están arriba.

39. Paso 5 - ¿Qué pasa si..?
 Imaginar que se tiene una
reunión muy importante a la
que no se puede faltar o
llegar tarde.
 Desafortunadamente el
despertador no sonó y te
quedaste dormido.
 Tienes 15 minutos para
llegar a tu oficina.
 Trazar una línea que permita
identificar las actividades
que les permita llegar a la
oficina con la menor cantidad
de actividades posibles.

40. En el juego..

41. En el juego..

42. En el juego..

43. Lecciones del juego
 Con la limitación del tiempo, el objetivo sigue siendo realizar el
pleno "valor" de llegar a tiempo a la oficina.
 Con la restricción de tiempo queremos ser rápidos, lo que
significa minimizar el tiempo para alcanzar el valor.
 No invertimos igual en cada paso, en algunos pasos dejamos
solo una actividad y en algunos muchos.
 Elegir la profundidad de cada paso es más fácil cuando la
imagen completa está disponible.
 El contexto del valor de extremo a extremo, ayuda a los
equipos de desarrollo a comprender mejor el alcance.

44. Referencias bibliográficas
 “Wake up in the morning”
Game – A quick fun way to
understand the basic
concept of Iterative
Incremental Development
 https://www.agilesparks.com/blo
g/wake-up-in-the-morning-game/
 User Story Mapping in
Practice
 https://submissions-
production.s3.amazonaws.com/
attachments/attachments/000/
000/077/original/UserStoryMap
pingInPractice.pdf
 User Story Mapping – Jeff
Patton.

45. Sesiones de agilismo
Construyendo el
Producto Mínimo Viable con
User Story Mapping
Gracias!
Agile La Paz