Semana 2 Mapa de historias de usuario

1. MAPA DE HISTORIA
DE USUARIO
Mg. Richard E. Mendoza G.

3. https://www.youtube.com/watch?v=AorAgSrHjKM

5. User Story Mapping es una técnica que Jeff
Patton describe en 2014 en su libro "User Story
Mapping: Discover the Whole Story, Build the
Right Product", y es muy útil para construir una
pila de producto que vaya más allá de una lista
unidimensional de historias de usuario y epics.
USER HISTORY MAPPING
• Producthttps://www.amazon.com/User-Story-Mapping-Discover-
Product/dp/1491904909/ref=sr_1_1?s=books&ie=UTF8&qid=14667
37683&sr=1-1&keywords=user+story+mapping

6. El backbone o espina dorsal del User Story Map captura las
actividades de alto nivel que un usuario va a realizar cuando use el
producto que se quiere construir. Por ejemplo, el backbone de un
proceso de compra de un libro en formato digital en una web de
venta de libros on-line sería:
Backbone del User Story Map

7. Historias de usuario asociadas con
cada actividad del proceso ordenadas
por valor (las más valiosas en la parte
superior): para cada actividad que va
a realizar el usuario con el producto
se definen las historias de usuario
que le van a permitir realizar la
actividad. Luego ordenarlas de arriba
abajo colocando las más valiosas o
prioritarias más arriba.
USER HISTORY
Para el ejemplo de la compra de un libro en
formato digital en una web de venta de libros,
un conjunto de historias de usuario asociado a
cada actividad y priorizadas por valor de arriba
hacia abajo sería:

8. Mínimo Producto Viable (v 1.0) y las siguientes versiones que se
prevé liberar del producto: se determinan cuáles son las historias de
usuario que compondrán el Mínimo Producto Viable (v 1.0) y las
siguientes versiones reflejando esto en el User Story Map, como por
ejemplo:
MINIMO PRODUCTO VIABLE

9. ¿Cuál es la
versión mínima
de una
hamburguesa?

10. • R0: Dos panes y una carne
• R1: Más salsas
• R2: Más tomate, lechuga y cebolla
• R3: Más queso y tocineta
• R4: Más otra carne
• R5: Más papas y gaseosa
• R6: Más postre
• Etc, etc, etc
Versionemos

11. La versión mínima
de hamburguesa
sería el Walking
Skeleton

12. Una vez que se ha llegado hasta aquí,
el equipo puede hacer una estimación
inicial del esfuerzo necesario para
realizar cada historia de usuario. De
esta manera el Propietario del
Producto puede tener una estimación
del esfuerzo requerido para
desarrollar el MVP y cada una de las
versiones definidas en el User Story
Map. Si conoce la velocidad del equipo,
es decir, cuántos puntos de historia
puede hacer el equipo por sprint y la
duración de los sprints.
MINIMO PRODUCTO VIABLE

13. 1. Identifica primero los procesos
Tip: cuando el sistema es pequeño se identifican los módulos
2. Luego las actividades
3. Por último las funcionalidades o historias épicas
Nota:
En sistemas/productos muy pequeños solo habrá dos niveles
En sistemas/productos grandes es posible que hayan más de 3
niveles.
Generar valor de punta a punta (end to end), y logrando un Release
útil para el negocio
METODOLOGIA

14. Permite identificar Historias de Usuario faltantes en el Backlog,
planificar Releases, visualizar cómo se distribuyen las
funcionalidades de acuerdo a las diferentes áreas del sistema.
MAPAS DE HISTORIA
DE USUARIO

15. Son diferentes a los backlogs típicos de
historias de usuario en cuanto:
Hacen visible el flujo de trabajo o la cadena de
valor
Muestran las relaciones entre historias más
grandes y sus historias hijas
Ayudan a confirmar la completitud del backlog
Proporcionan un contexto útil para la priorización
Permiten planear entregas (releases) en porciones
valuadas y completas de funcionalidad
MAPAS DE HISTORIA
DE USUARIO

16. THE BACKBONE

17. ANATOMÍA DE UN MAPA DE
HISTORIAS DE USUARIO
El backbonede la aplicación es la lista de actividades
esenciales que la aplicación soporta
El walkingskeletones el producto (de software) que
construimos que soporta el menor número de tareas
necesarias a través de una experiencia de usuario
completa
The backbone
tiempo
The walking skeleton

18. Adiciona historias centradas en tareas bajo cada
actividad en el flujo de trabajo, de izquierda a
derecha.
– Si fueras a explicar a alguien lo que una persona hace
típicamente en esa actividad, ordena las tareas en el
orden en que contarías la historia. ¡Pero no te pongas
muy tenso sobre el orden!
tiempo
ADICIONA HISTORIAS QUE
INDIQUEN TAREAS DE USUARIO

19. Organiza las tareas de usuario verticalmente si un usuario debe
hacer más de una tarea casi al mismo tiempo
– Si al contar la historia dices que el usuario del sistema típicamente “hace estoo
aquello o esto o esto otro y luego haceaquello otro”, esas“o” sonseñalesde
apilamiento vertical, mientras quelos“y luego” sonseñalesdeordenamiento
horizontal.
tiempo
ORGANIZA LAS HISTORIAS
DE USUARIO

20. Leer las actividades en la parte superior del
sistema ayuda a entender el uso de punta a punta
del sistema. (Refiérete a estas cuando hables a
personas con lapsos de atención cortos.)
tiempo
Bajo cada actividad o
historia grande están las
historias hijas que la
componen
DESCOMPOSICIÓN Y FLUJO
A TRAVÉS DEL SISTEMA

21. Promueve el trabajo en equipo para organizar las historias
Busca actividades: tareas que parecen similares son realizadas por
personas similares en la búsqueda de objetivos similares
Usa colores diferentes para etiquetar/resaltar las actividades
tiempo
ENSAMBLAR LAS HISTORIAS
EN UN MAPA DE HISTORIAS

22. USANDO TÉCNICAS DE
CONVERGENCIA, LLENAR MAPA
Trabaja como un
equipo Busca tareas
alternativas
¿Qué más podrían hacer los usuarios del sistema que no
están en los escenarios actuales?
Busca excepciones
¿Qué podría salir mal y qué tendría que hacer el
usuario para recuperarse?
Considera otros usuarios
¿Qué harían otros usuarios para lograr sus objetivos?
Lleva todas esas historias adicionales a tu mapa

23. tiempo
opcionalidad
necesario
menos
opcional
más
opcional
primera entrega
segunda entrega
tercera
entrega
Selecciona grupos coherentes de características que se extiendan por
la funcionalidad del negocio y actividades de usuario
Incluye todas las actividades necesarias en la primera entrega
•Mejora las actividades ya incluidas y adiciona otras
actividades en las entregas subsiguientes
PLAN DE ENTREGAS

25. Una pizarra colaborativa virtual para
equipos distribuidos que es segura,
escalable, compatible con múltiples
dispositivos y pensada para tu
empresa.
MIRO

27. Jira es una herramienta en línea para la
administración de tareas de un proyecto, el
seguimiento de errores e incidencias y para la
gestión operativa de proyectos. La herramienta fue
desarrollada por la empresa australiana Atlassian.
Inicialmente Jira se utilizó para el desarrollo de
software, sirviendo de apoyo para la gestión de
requisitos, seguimiento del estado de desarrollo y
más tarde para la gestión de errores. Jira puede
ser utilizado para la gestión y mejora de los
procesos, gracias a sus funciones para la
organización de flujos de trabajo.
JIRA

29. EJEMPLO

30. PLANNING POKER
• Planning Poker es una técnica para calcular
una estimación basada en el consenso, en
su mayoría utilizada para estimar el
esfuerzo o el tamaño relativo de las tareas
de desarrollo de software. Es una variación
del método Wideband Delphi. Es utilizado
comúnmente en el desarrollo ágil de
software, en particular en la metodología
Extreme Programming.
• Secuencia de Fibonacci: 1, 2, 3, 5, 8, 13, 20,
40 y 100

31. • El Product Owner lee el elemento del Product Backlog
• El equipo comenta el elemento y para clarificarlo realiza
preguntas al Product Owner, quien las responde
• Cada estimador selecciona una carta que representa su
estimación, se mantienen en privado hasta que todos hayan
estimado
• Si todos seleccionaron la misma hay consenso
• Si no, se discuten supuestos preguntando primero a quienes
tienen estimados extremos
31
PLANNING POKER

32. • Todos estiman de nuevo y se selecciona el valor para la historia:
• Promedio
• Frecuencia
• Consenso
• Las estimaciones se van haciendo comparando el tamaño con la
estimación de elementos estimados anteriormente y de similar
esfuerzo
• Se inicia estimando una historia de usuario que sirve de referencia
para las demás
PLANNING POKER

34. PROYECTO
• Definición del Producto
• Grupos de 5 personas(Product Owner, Scrum Master y Team Developer)
• Definir una página Web (Empresa, Quienes Somos, Misión, Visión, Objetivos
Corporativos, Organigrama(opcional), 3 productos)
• Desarrollo Frontend y la publicación (HTML- CSS)
1. Historias de usuario - Como, quiero y Para – https://jira.com/ - Product Owner
1 pantallazo.
1. Planning Poker – Pantallazo de planning póker – https://scrumpoker.online/
Scrum Master - Product Owner-Team Developer – 1 pantallazo
2. Planear un Sprint Backlog, Scrum Board -
https://www.atlassian.com/es/software/jira – Scrum Developer - 1 scrum
board
3. Archivo .pdf