Este documento resume las actividades y técnicas recomendadas para realizar antes del primer sprint de un proyecto ágil, incluyendo definir la visión del proyecto, identificar a los involucrados, analizar riesgos, establecer requisitos no funcionales, crear personas y mapas de historias para generar el backlog de producto, y elaborar un producto mínimo viable. El autor también recomienda utilizar herramientas visuales como el tablero de visión de producto, el mapa de riesgos, el mapa de historias y el tab

1. Incepción Ágil
Todo lo que ocurre antes del primer sprint
HELP!

2. Hiroshi Hiromoto
CSP | CSM | PMI-ACP | CSPO | CSD
Agile Consultant & Trainer

3. La historia de Mike

4. La historia de Mike

5. Soy Mike!
Trabajo
como Project
Manager

6. Reconocida
empresa de
desarrollo

7. Método
Ágiles
Scrum
XP
Kanban
Iterativo
Valor
Incremental

8. ?

9. Mike
anda al
curso!

10. Mike

11. Manifiesto
ágil
Principios
Valores

12. Visión
Backlog
Daily
Meeting Sprint
Review
Sprint
Retro
Sprint
Planning

13. Esto es
genial!

15. Quiero hacer un proyecto
con Scrum!
Director de
desarrollo

16. 2 semanas después

17. Tu propuesta para
usar Scrum ha sido
aprobada!

18. =D

19. Muchachos el
Lunes tenemos
Sprint Planning

20. Sprint Planning Tips
- Timeboxea la reunión.
- Ten el backlog refinado.
- Ten el backlog priorizado.
- Repasa la visión al iniciar
la sesión.
- Comunica al equipo en que
parte del producto se desea
hacer enfoque.
- Repasa el Definition of
Done.
- Recuerda que debe estar
presente todo el equipo.
- Recuerda que el equipo
estima.
- ...
Tengo que
recordar los
tips!

21. !

22. Visión?
Roadmap?
Backlog
refinado?

23. Visión?
Roadmap?
Backlog
refinado?
Definición
de
Terminado?
Equipo
alineado?
Riesgos?
Prioridad?

24. HELP!

25. Aquí falta algo!
(que Scrum no te dice)

26. HELP!
Yo te
puedo
ayudar!
Agile
Consultant

27. Si bien
Scrum no lo
explicita Hay
trabajo
previo al 1er
sprint

28. A cont.
Tips y
Técnicas

29. Genial!

30. Todo lo que ocurre (o podría ocurrir) antes del
primer sprint

31. Comencemos

32. Disclaimer: Cada una de las técnicas que se
mencionarán podrían tener su propia charla, en esta
ocasión el foco será en dar un visión general de lo
que se puede hacer antes del primer sprint

33. Todo
inicia con
un “WHY”

34. Lo primero que tenemos
que asegurar es que
todos los miembros del
equipo entendamos la
principal razón del
proyecto!

35. Entonces antes de
iniciar el proyecto,
convoco a todo el equipo
y se explica la razón
principal del proyecto.

36. TIP: Recuerda que no
sólo es importante que el
equipo sepa esa razón
sino que la entienda (el
transfondo).

37. OK!
Luego? Una visión!
No solo
debe
existir!
Visible y
compartida

38. El Product Vision Board
es una herramienta visual
que permite construir la
visión de un producto.
Codename Frase representativa
Grupo de
usuarios
Necesidades Producto Valor

39. El codename es el
nombre que usará el
equipo para referirse al
proyecto. Entre todos
busquen un nombre
creativo que los relacione
al proyecto.
Codename Frase representativa
Grupo de
usuarios
Necesidades Producto Valor

40. La frase representativa
debe ser corta y precisa,
debe expresar el alma del
producto y ser nuestro
nexo hacia lo que aspira a
ser.
Codename Frase representativa
Grupo de
usuarios
Necesidades Producto Valor

41. Identifica los grupos de
usuarios que utilizarán el
producto. ¿Para quién
estamos trabajando en el
proyecto?
Codename Frase representativa
Grupo de
usuarios
Necesidades Producto Valor

42. ¿Cuáles son las
necesidades de tu grupo
de usuarios? Aquí se
encuentran las razones de
ser de tu proyecto.
Codename Frase representativa
Grupo de
usuarios
Necesidades Producto Valor

43. ¿Qué características de
tu producto satisfacen
las necesidades de tus
usuarios? No necesitas
hacerlo a gran detalle.
Codename Frase representativa
Grupo de
usuarios
Necesidades Producto Valor

44. Codename Frase representativa
Grupo de
usuarios
Necesidades Producto Valor
¿Qué valor le genera al
negocio la satisfacción de
la necesidad del grupo de
usuario a través del
producto?
Movimiento
obligatorio!

45. Codename Frase representativa
Grupo de
usuarios
Necesidades Producto Valor
Entonces con el Product
Vision Board todo el
equipo sabrá desde el
inicio para quién, por
qué y qué valor
brindamos al realizar el
proyecto.

46. TIP: Utiliza siempre (que
sea posible) una pizarra
física y promueve la
participación de todo el
equipo mediante la
interacción con ella.

47. Nota: A veces utilizo una
variación en la columna de
valor y coloco el valor
para el usuario final.
Cuando hago esto coloco
también dentro de mi
grupo de usuarios a mi
cliente/sponsor.

48. Tengo
mi visión,
ahora?
Conoce
a tus
vecinos
Ah?
Vecinos?

49. Sí! Lanza la siguiente
pregunta: ¿Quiénes son
los involucrados en este
proyecto (fuera del
equipo)?

50. Plasma el mapa de tu
equipo y sus vecinos
físicamente y muéstralo
al resto, de seguro
alguno identifica a uno
nuevo!

51. Entonces no es
suficiente que yo crea
que sé quienes son los
involucrados sino que lo
debo tener visible y
corroborarlo.

52. Interesante
hay más?
Ahora
veamos
riesgos

53. Toca preguntarnos: ¿Qué
nos mantiene despiertos
en las noches?

54. <inserta tu riesgo favorito>
Genera una lista con las
cosas que te preocupan
del proyecto, aquellas que
no te dejan ir a dormir
tranquilo

55. Es bueno saber que
cuando trabajamos con
Scrum también
pensamos en riesgos!
<inserta tu riesgo favorito>
Un ataque de zombies!

56. <inserta tu riesgo favorito>
TIP: No te quedes solo
con la lista, priorízala y
toma las medidas que
creas necesarias! Por
cierto, tampoco abuses
con la longitud de la
lista!!
Un ataque de zombies!

57. OK,
entiendo
Ahora
solo falta
decir...
que
cosas NO
van a salir!

58. Pon visible y comunica las
cosas (funcionalidades)
que NO se van a hacer.
Muchas veces las
asumimos, pero al decirlas
genera un conocimiento
compartido. Además le da
foco al equipo sobre lo
que debe construir.

59. Además así puedo evitar
malos entendidos con los
involucrados y setear
expectativas!

60. ¿Qué
opinas hasta
ahora?
Bien! Qué
sigue?
Toca
¡cómo llegar
al backlog!
Y para eso
usaremos
algunas
técnicas

61. Definamos
personas

62. Personas es una técnica
que nos permite crear un
esteriotipo de nuestros
usuarios y nos ayuda a
ver el producto desde el
punto de vista del
usuario. Si hemos hecho
antes el PVB las personas
deberían estar en uno de
los grupos de usuario
definidos.

63. Una forma práctica de
generar personas es
usando este template
Nombre
y Foto
Características Necesidades

64. Comienza poniéndole un
nombre y una foto
Nombre
y Foto
Características Necesidades

65. Ahora sigue con las
características de la
persona. Puedes incluir su
ubicación, su trabajo, su
estilo de vida, etc.
Nombre
y Foto
Características Necesidades

66. Finalmente determina las
necesidades que tiene
esa persona que la harían
utilizar (comprar) el
producto
Nombre
y Foto
Características Necesidades

67. Nombre
y Foto
Características Necesidades
Ya veo. Y esto lo utilizo
para cada uno de los
esteriotipos de usuarios
que tengo.

68. Nota: Existen muchas
formas de definir
personas, busca la que
más te acomode!
Nombre
y Foto
Características Necesidades

69. Y esto
¿cómo me
acerca al
backlog?

70. Con la
siguiente
técnica lo
verás!

71. Es una de
mis
favoritas!!

72. El Visual Story Mapping
es una herramienta visual
que mapear las
funcionalidades de un
producto contextualizado
a un escenario. Su
elaboración permite
generar de manera más
sencilla el Product
Backlog

73. Y como toda herramienta
colaborativa lo más
importante son las
discusiones y
conversaciones que se
generan en su elaboración

74. En líneas generales el
mapa se construye de la
siguiente forma.

75. En primer lugar definimos
el proceso/actividades de
alto nivel, que tienen que
ver directamente con el
proceso de negocio que va
a estar relacionado con el
producto
A A A A

76. Luego tomamos a
nuestras personas
definidas previamente y
las colocamos en el lado
derecho del mapa
A A A A
P
P
P
P

77. TIP: Prioriza tus
personas, y deja a la más
prioritaria en el tope de
la lista
A A A A
P
P
P
P

78. A continuación tomamos
una persona y contamos
las tareas que realiza,
mapeándola con el
proceso definido. A esto le
llamo definir una travesía
de la persona.
A A A A
P
P
P
P

79. Ahora utiliza la misma
persona y genera una
travesía alternativa.
A A A A
P
P
P
P

80. Así sucesivamente para
todas las personas
A A A A
P
P
P
P

81. TIP: Involucra a todos los
miembros del equipo en el
armado, recuerda que lo
importante son las
discusiones que genera.
También procura contar
una historia al generar
las travesías.

82. Entonces son esas
tareas de la persona las
que serán
transformadas en una o
varias funcionalidades
que poblarán mi backlog!

83. Wow! Ya vi
la luz!

84. Ya puedo
hacer mi
backlog

85. Antes de
eso, quiero
hablarte de un
concepto más

86. Se llama Producto
Mínimo Viable (MVP) y
es usado mucho por
emprendedores, pero
también te será muy útil
A A A A
P
P
P
P

87. El MVP busca que
indentifiques las
funcionalidades mínimas
para que puedas salir a
producción y se puede
muy fácil utilizando el
VSM
A A A A
P
P
P
P

88. Solo delimita con una
línea el (las) travesías
mínimas indispensables
para que el producto dé
valor y tenga sentido! Y
ya tienes tu MVP
A A A A
P
P
P
P

89. Entonces mi MVP
termina siendo mis
funcionalidades más
prioritarias y las que
van arriba en el Backlog
A A A A
P
P
P
P

90. TIP: Busca en realidad
lo mínimo! Recuerda,
busquemos minimizar el
output y maximizar el
outcome
A A A A
P
P
P
P

91. Creo que
ya estoy listo
para mi 1er
sprint!
Sí! Solo
te dejo un
tip más

92. El Product Backlog
Board es una herramienta
visual que le permite al
equipo tener centralizado
todos los elementos de
información necesarios
para trabajar los items
del backlog
Área de
personas
Área de
historias
Área de
restricciones
Área de
modelado

93. En el área de personas
colocamos nuestras
personas elaboradas
anteriormente. Hay que
recordar que ellas
representan a nuestros
grupos de usuarios
definidos en la visión
Área de
personas
Área de
historias
Área de
restricciones
Área de
modelado

94. En el área de historias
coloca tus historias listas
para trabajar y las que
están en cola. Es
básicamente tu Backlog.
Área de
personas
Área de
historias
Área de
restricciones
Área de
modelado

95. En el área de
restricciones coloca tus
requerimientos no
funcionales y el diseño de
la interfaz
Área de
personas
Área de
historias
Área de
restricciones
Área de
modelado

96. Área de
personas
Área de
historias
Área de
restricciones
Área de
modelado
Finalmente, en el área
de modelado coloca
cualquier diagrama (flujo,
modelo, etc) que le sirva
de guía al equipo durante
el desarrollo
Movimiento
obligatorio!

97. Nota: En algunas
ocaciones cambio el área
de personas e historias y
la reemplazo directamente
con el VSM.
VSM
Área de
restricciones
Área de
modelado

98. Área de
personas
Área de
historias
Área de
restricciones
Área de
modelado
Con esto no solo tengo
el Backlog visible sino
también los
requerimientos no
funcionales, las
interfaces de usuario y
los flujos y procesos del
modelado

99. Que te
pareció?
Ayudó?
Si! Ya tengo
más claro qué
hacer antes del
1er sprint

100. Muchas
Gracias! :)
Un gusto
ayudar!

101. Disclaimer: Esto ha sido un conjunto de
recomendaciones en función a experiencias que he
tenido, no es una guía absoluta!

102. Referentes en el tema
@jrasmusson @davidhussman
@romanpichler @jeffpatton

103. Dos buenos libros

104. Los
invitamos a
Ágiles2013!
El 10, 11, y
12 de Oct.
bit.ly/agiles2013

105. Hiroshi Hiromoto
CSP | CSM | PMI-ACP | CSPO | CSD
Agile Consultant & Trainer
Preguntas?
@hhiroshi
hiromoto.hiroshi@gmail.com